When I’m not writing, I am an IT Project Manager and Business Analyst with over 20 years’ experience working across the public and private sectors in New Zealand and Australia.

Currently I am working on contract as an applications Project Manager with NZ Police.

The purpose of this page is to share some of my insights and observations from working in the IT industry on topics related to Project management, Business Analysis and Agile Software Development.

 

I expect to add to this page over the coming months.

 

For more information about my professional background see my LinkedIn profile or via my current CV

Why conversation is more important than requirements

The most commonly cited reason for project failure (at around 50%) is poor understanding of requirements. How can any project team be confident they will reach their goal, if they don’t have a common vision of what the goal is?

Unfortunately, some organisations seek to tackle this dilemma by sinking more time and investment up-front in the definition of detailed requirements.

You may be thinking detailed requirements are good, right?  It shows the business team have invested a significant amount of cost and effort into defining exactly what they want. This is indeed desirable, but the approach has its roots in Waterfall thinking, whereby the project seeks to eliminate uncertainty risk by documenting as much detail as possible into the requirements before a line of code is written.

There are a number of problems with this approach:

 

  • It delays the commencement of development (which could be critical if you are operating in a competitive environment where time to market is a defining success factor for your project.)
  • Trying to cater for all possible outcomes up-front often results in delivery of a product that contains superfluous features which will never be used.
  • You can never eliminate uncertainty – there will always be things the project team simply don’t know until they start to deliver the project.
  • Even if you manage to eliminate uncertainty at the outset, it is naïve to believe everything is set in stone – requirements can (and likely will) change over the extra time it takes to define them, or as the project progresses and the team or business learn more.

 

Even if somehow you manage to avoid the pitfalls above, there is still the issue that even if your requirements are detailed, correctly identified and prioritised, in a siloed organisation where requirements are tossed over the fence to the delivery teams, the requirements themselves could be correct, but the intention behind them still misunderstood. While a subtle distinction, often the intention behind a requirement can be fundamentally as important as the requirement itself and can have a significant impact on the design a project team chooses to implement a feature.

At worst, misunderstanding of the intent behind requirements can result in a product being delivered which, while technically meeting all of the requirements specified, doesn’t meet the needs of end-users.

At best, the delivery team will need to spend time interpreting the intent, especially if they are need to break down traditionally documented requirements into User Stories for iterative development. This leads to delay in the team making early progress on development, as well as frustration between the business and technical teams. The business representatives, who have often invested significant time in developing the requirements, can see this as the delivery team re-litigating the requirements. “Why are you asking all of these questions instead of just getting on with the job?”  In reality the delivery team are trying better to understand the opportunity or problem to be resolved.

 

 

Fortunately, much of this can be mitigated by involving the delivery team in conversation early in the process, rather than handing over a set of completed requirements as fait accompli.

Conversation is about transferring  knowledge from one team to another, rather than transferring a set of documentation. As a former runner, the analogy I think of is a relay. Before the delivery team receive the baton, they should’ve been engaged in conversation to understand the goal of the requirements, so they are already running at near top speed by the time the baton reaches them. Receiving requirements and then being asked to commence is akin to being handed a baton from the previous runner, while at a standing start.