At work recently we’ve been tasked with finding out if/why our group is at all special. A consultant has appeared before us to point out his view of the dimensions along which a team might excel (tools, techniques, process, skills, attitude, or discipline). And we’ve been told that as a “shadow” IT group that wants to not be be squashed by the lumbering corporate IT organization, we had better figure out our case quickly.
The consultant brought with him a strong bias toward teams distinguishing themselves based on process. This is understandable simply in light of the fact that he is associated with the Center for Project Management, which would be necessarily focused on process issues. He attempted to impress upon us that in a presentation to managerial types, people variables (skills, attitude, discipline) would not be seen as distinguishing factors, since the value of the group could not then be seen to live on independently of the individuals who currently comprise it.
This is controversial. I suspect most team members believe that we excel primarily in attitude and discipline. There’s nothing unique about our tools, techniques, or skills, and our process remains quite poorly defined, overall. We’ve toyed with RUP, but discarded anything requiring a large number of artifacts or really much documentation at all (heresy, I know). And we are continually adjusting, trying new things, mucking about with how we do business.
I find a small amount of kinship in Agile methods, in that the focus is on continuous realignment with customer needs. We have clearly rejectd the old waterfall manner of development, but haven’t fully embraced UCD techniques or really any of the other popular alternatives.
I think the difference might be that we expect projects to be poorly defined, requirements to be generally crap, and so we take a consultative role in things we’re really not qualified to, primarily the definition of the goal itself. People ask us for a tool that does X, and we ask, “what do you want X done for?” People claim they need a web application that follows some use cases they’ve cobbled together, and we mangle those use cases (in the nicest possible way). Managers throw work over the wall, and we throw it right back, climbing over the wall to follow it. I suppose this is process, but it really springs from interest.
