Any project management methodology will teach you that to be a good project manager you need to write everything down and get everything signed off. That way the "legals" are bullet proof, you have evidence that the customer asked for it and anything not written down is completely out of scope.
I admit to taking this position on numerous occasions myself. At some point in most IT workers careers they have been burnt by scope creep. The delivery date is set but the customer needs much more to be delivered in the software than you have built. Most IT workers would have stayed late for nights, weeks, or grueling months to squash additional scope into software deliveries.
This usually is a result of a number of bad news conversations, some you may recognize sound like this:
IT worker: You didn’t ask for that [feature/function]
Customer: I may not have asked for it specifically, but it’s not going to work without it. How come you didn’t know that?
IT worker: erm….let’s ask the Business Analyst!
Business Analyst: I pointed it out at the time but we no one thought it was important…[or]….You told me to get the requirements done in 4 weeks which was not enough time…[or]…..We had to reduce scope/cost
Customer: It doesn’t matter how or why, we just need it, and we need to hit that date.
[Queue overtime and rushing in late changes]
I believe it’s this common negative experience that leads to the defensive position of writing everything down and signing everything off.
Sophisticated IT organizations have change management processes to control this kind of scope creep. Others have grumpy and tired IT workers who vow never to work this way again and to institute writing everything down and signing everything off (In ink please, and PDF’ed and stored on the network drive) as soon as possible.
Is there an alternative better result we could obtain using Trust and Collaboration? What would that look like?
We recently completed an inception phase for a new project at my organization. We used external experts in Agile development methodologies (ThoughtWorks) and went through a process they have established called a ‘QuickStart’.
It took the form of two intensive weeks of collaborative workshops with all major stakeholders for the project. The results were really positive at determining the scope and more importantly, prioritization of the scope for the project.
Two of the most useful outcomes I observed were:-
- Nothing is discarded, everything is captured somewhere, whether on a post-it note, or on a poster, or index card. But again and again the high priority items bubble to the surface. By the end of the process the group had a shared understanding of what was really important for this project, and it’s not represented in a long winded MS word document.
Maybe this is the antidote to last minute requirement gaps found in many traditional projects.
- There was almost unanimous praise for the process of working collaboratively between business and IT.
I strongly believe this is the right way for software to be built. I’m not a fan of writing everything down so IT workers can go away for six months building software from a document. I know we get a better result – better software that adds more value and less waste – by strong collaboration between IT and business people.
To quote Mother Teresa:
“To trust your people you must know them, to know them you must love them”
Hug your business customer today!