Skip to main content

Trust and Collaboration

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:-

  1. 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.

  1. 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!


Popular posts from this blog

Business Requirement Documents are just no good and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 
If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.
Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to …

Gamify your children

Inspired by James Ross’s LAST conference talk on The Shamification of Lamification and the Reclaimification of Gamification I was motivated to try and “Gamify” the school holidays for my three children, Leo aged 8, Chloe 9 and Max 10.
Buy-in is everything, so the first thing we did was a quick workshop to extract the kids ideas. I asked them to write their ideas for good rewards on sticky notes, with a few examples for context, such as ‘trip to the movies or ‘play date with a friend’ . They had 5 minutes to come up with their ideas – one idea per sticky note (as always).
They then read out their ideas for all of us to hear, there were a few duplicates and also a few comedy suggestions. Even though we had ruled out crazy stuff, such as rewards of a million dollars, Leo had written down ‘A unicorn for the back yard’ reading it out with gleeful giggles.
Then they spent 5 minutes writing down tasks that they could do to earn rewards. By now they had the hang of it and quickly came up with t…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …