I have been thinking recently about the culture of a corporate organization and how our own fears and insecurities can lead to disastrous results. IBM best encapsulated this insecurity with their commercial “Nobody ever got fired for buying IBM”. In the 1980’s when IBM was competing with PC clones producing cheaper machines this advertising theme was used to imply that picking IBM was a “safe” choice, one that would never be held against you.How often is this concept applied to the process, artifacts and ceremonies accompanying IT projects in major organizations?

In fact, this is probably the insidious challenge with things like RUP or PMBOK, which advocate selectively choosing the tools and artifacts you need for a specific project. While people are free to opt to exclude certain deliverables, in an unhealthy organization, one does so at their own peril. Any gap or inconsistency is likely to be pointed out in a postmortem as the ultimate mistake that doomed a project. Scope had to change? Clearly you should have done both a business requirements and then a system requirements document. Project schedule slipped because too many bugs were found late in the game? Looks like you really should have made a formal QA strategy document and a full traceability matrix mapping your requirements to test cases.

Ironically, this very dynamic can play against Agile. I was facilitating a discussion about Agile and one of the participants earnestly explained to me that they needed to write detailed technical specifications because so much of their work was sent offshore to the lowest bidder, where turnover was so rampant they were working with different people every 3 months. The idea that they should improve their off shoring strategy did not seem to be worth considering. I wish the team luck, but I wouldn’t be surprised if several months from now, they found themselves looking over a steaming pile of project wreckage and saying, “well, that’s why we shouldn’t use Agile and need to put together detailed specifications before we ever start coding!”

This draw is particularly relevant to me, as I would identify myself as a reformed process-aholic. When I was a newly minted PMP in my first project management role, there wasn’t an optional template, process or document that I avoided. Project charters, team orientation manuals, risk spreadsheets, progress dashboards, business requirements, testing strategy documents, data dictionaries, you name it my project had it. Nobody would say that I wasn’t managing my project well or that I was neglecting something. Of course it means that I authored a lot of documentation nobody read, and it wasn’t clear what the team had truly agreed on – were testing guidelines in the unit test strategy, the project plan, or the system test strategy – and incidentally I was so busy filling out documents that I wasn’t really around to help the project team. I do seem to recall complaining that nobody followed the beautiful plans I had put together. What I didn’t appreciate is the idea that everything you do in a project has a cost. Now many things don’t cost much, and are well worth the investment, but process isn’t free. Every minute we spend documenting something is a minute not spent collaborating. While documents are useful for historical context, they can also become inaccurate over time, or continue to cost more if they must perpetually be maintained. What is the cost of the fact that now, when people have a question, they go to the document instead of asking the subject matter expert, who would be able to explain much faster and effectively?

Interestingly enough, it seems many people, especially in large bureaucratic organizations realize that is these unwieldy processes that can ultimately consume so much time and energy they are effectively undermining the project. Perhaps its human nature that those of us closest to managing a process are at risk of becoming consumed by it and perceiving all problems as challenges to be solved with more process.