Recently, we’ve been practicing what I like to call “project archeology.” Almost four years ago, I joined my current team to work on a rewrite of an old IMS/CICS based accounting system. We were designing a new data model, switching to DB2, and moving to a web based user interface courtesy of Java. Things were really cranking along until our senior executives do what they do best: they announced a “merger of equals.” Needless to say, our world hasn’t been the same since.
During integration (and some would argue its still going on) my project was essentially on hold. For quite some time, it sure seemed like my project would whither on the vine but for reasons that aren’t entirely clear, its back. Over the course of the year and a half that was integration, a number of things have changed – we’ve got new management and several team members have moved on. But as I said in an earlier post, abandon all hope for a better past.
So what does that have to do with project archeology? Our new PM is going through all of our old documents trying to answer two very interesting questions: what did we promise our customers and what do we have left to deliver. While its hard to answer the later without knowing the former, we really have a firmer hold on what’s left than what the target is/was. Anyway, its been quite fascinating to peer back and try to remember what someone might have meant by “Foo feature must perform better” (a real “requirement”) and figure out what features might have been tested.
But what does this have to do with formality? Over the years, my company has used a number of different methodologies with all the requisite templates and forms. Now, I never really knew what any of these documents were supposed to prove other than methodologists are the cockroaches of IS – you just can’t kill them. Seriously, it doesn’t matter how many reorganizations a shop goes through, they just don’t die. The tend to change names a lot though… OK, enough of that rant. I have to admit, I wasn’t on the project when much of what we are now dissecting was written, but it sure looks to me like all the “process” we followed at the time is doing much to help us today.
As I was sitting in a project meeting last week, I was reflecting on the difficulty we are having piecing our past back together and I was wondering if a greater level of formality would have helped our project. A friend works at a shop that is actively seeking CMMI level 3 and my first reaction was – why? I’m a big fan of agile approaches since they seem best positioned to deal with the inevitable change of software (and I can’t help but like the importance of people in these processes.) But you know what? After a few months (don’t ask) figuring out where we are and where we were trying to get to, I’m starting to wonder what the right level of formality is on a software project.
I don’t have any answers but I sure do have some questions! What affect does company culture have on the need for formality? Does the type of application matter? What’s the right level of formality? I’m not ready to run out and champion CMMI at my employer, but next time I join a project “in the beginning” I think I might try and impose a tad more discipline.
