Diaries of a Project Manager – Requirements Gathering
There are days in my working career when I reflect and think, not even the best comedians could write this stuff.
I recently caught up with a PM I worked with once upon a time. I was getting the low-down on the a project he’d been working on for a few months. The internal customer (who is a member of the IT ‘Leadership’ team and not the end user) was extremely anxious for progress. The supplier of the product (external software development house) had very little in the way of a delivery process, pipeline management capability and zero requirements. The IT delivery team was for all intents and purposes, blind and stuck in the middle. To add insult to injury the IT ‘Leadership’ team considered this to be a ‘small’ project and therefore a) no requirements necessary and b) had little to no understanding of the product purchased. But in true corporate style, IT is here to enable the business and as such who are we to stand in the way?
- Business requirements? 3 bullet points in a random email 6 months prior to delivery commencing.
- End user engagement? What do you mean? Bob from Accounts has been assigned but he is very busy at the moment with year end and his day job…so no we cant spare him for a day a week. Further, the PM had never met an end-user, nor were they aware the project was underway.
- Product selection? The business and internal customer (both of whom were not users of the system being implemented) heard it was the quickest way to market – hence the brevity of the initial requirements (3 bullet points).
- Business process? Whose process do you mean?
And the list of curious questions and numpty answers continues…
The crisis scene in this short documentary is best described as a Come-to-Jesus crisis meeting. Seven managers sitting around a large boardroom table; perplexed, angry, despondent and one very worried PM. After some robust discussion, it was agreed that the product was not ‘fit for purpose’. Mr PM was sent back to his desk to re-write the project plan, re-scope the delivery with a different product, re-finance the project and present back in 24 hours. And yet, sadly, there are still no requirements.
Sigh. Long pause. Sad eyes. A pat on the shoulder to my darling friend, the PM.
Why does this happen?
How can the business understand what is needed if they have taken the time to explore and document the As Is/To Be processes within their own domain? How can they really consider the products to meet their business needs without understanding how they want to operate – in detail?
Unfortunately for Mr PM, the IT ‘Leadership’ team in this instance didn’t provide the required support and the project has continued on. An alternate and much unwanted product was selected, the process reverted to the traditional process and the business now has little ability to improve its profit margins.
Just like the principles we hold dear in life, the same holds true in project management. Take accountability. Just because a project is deemed small, does not mean we apply no process at all. And when your organisation or client says they don’t need to collect requirements, (which is often communicated as ‘we don’t have the time or money to invest in collecting business requirements’) we need to push back and say no. Disasters like this cost the business time and money and, are absolutely avoidable if you take accountability and apply due diligence. In closing, a word from the wise:
- Requirements Gathering is a must. Never agree to deliver a project sans requirements. If you do, more fool you.
- Good requirements means end-user know how and a well documented As Is / To Be business process. Often, the business aims to improve through the use of new technology, but without understanding how your internal process will improve, no software solution will achieve your goals. It is important to improve within and then embark on the journey is IT product selection. You’ll know the product is right for you, when it meets your required improvements.
- IT project management and project management processes are known. They have been finessed over many decades. There is a good amount of evidence to suggest that following them leads to successful delivery. Use them. It is you are not an IT aficionado, a quick Google search will give you enough information to initiate your projects correctly…then defer to an expert.
- Failed projects cost your business money and valuable time. Unless you are Agile and fail to learn. Which is another blog entirely…