Requirements Gathering

Requirements Gathering

The Lost Art of Story Telling in Technical Projects...

Project management as a discipline has been around for many decades in its modern form yielding new methodologies and approaches in its path. Company adoption of these tried and tested approaches vary with technology in the lead for pioneering new approaches and iterating over current versions in cycles of continuous learning and improvement. So bearing this in mind, why does the infamous Standish report IT software project success at 16.2%?

In exploring this answer, it is noted that senior management awareness of modern project management and what it entails is a great help yet often absent. So let's move on to what is inside the project team's sphere of influence. Proper planning, user participation and clear requirements matching clear expectations from the project are within the project teams sphere of influence yet are cited causes of IT project failures. When one thinks of these noted causes of failure in IT projects, the kernel place of requirements gathering becomes very clear. Given that proper requirements are needed to match expectations for the project, engaging user participation in a credible manner along with forming the basis of the project management methodology to effectively plan it; the art of effectively gathering requirements becomes the number first step in any successful project.

Approaches will vary in often impacting ways but in general terms, the project manager needs to prioritize this task at the inception stages of the project and make sure the project story can be told in requirements. One sets the scene with non-functional requirements detailing the environment for the software's function and then details functional requirements of what the software does that supports the project's goals. For example, if you want to build and deploy a highly available greenfield app in the cloud, then set your requirements to tell the story of what your app does, what level of access it has and where it lives. This high-level overview of requirements is often left at that, which is why IT projects fail. 

So if you are tasked with gathering projects for your project, here are some must-haves that should not be overlooked to gather requirements for success:

  • Prioritization - Prioritize your functional and non-functional projects using the MoSCoW prioritization model of 'Must Have', 'Could Have', and 'Wish We had'. This adds realism to your requirements and identifies unrealistic or out of place requirements at the outset saving time and money.
  • Detail - If a project requirement is too general for your liking, then it is too general to act on with confidence. Don't move past the requirements gathering stage when there is room for two 'correct' interpretations to a requirement point. Tie the contributor down to singular detail matching it to the project goals and expectations as you know them. Use the opportunity to get background from the contributor so the depth of understanding is added to your requirement increasing its efficacy.
  • Requirements planning - Make sure you have allotted a fixed amount of time to requirements gathering to quantify what is a period of qualitatively gathering and/or analysing those requirements. If you only have a fraction of your requirements in place to your plan, your requirements work will roll over time-wise. Make sure key stakeholders are informed of this slow start and the reasons why. There is often management pressure to get it done yesterday, force obscure requirements to the top of the list and drop requirements without explanation. This is less likely when there is good communication established from the outset with key stakeholders. This should begin after the statement of work is defined with project goals and key stakeholders identified. 
  • Communication - Communicate regularly with key stakeholders on where you are at in the quantification of requirements, assessment of them and development of project methodologies and plans. Also, maintain the established cadence of communication throughout the project.
  • Immutability - No matter what requirements are processed, when the project heads into the implementation phase make sure your requirements are locked down regardless of the project management approach. This can be a long and extensive marker like with the waterfall approach, or a short cyclical marker for a build in the iterative approach. 

There is no fully right or wrong way to manage projects as it's always determined by the use case and circumstances around the project. That said, we now know why projects fail as a whole in technology and should use these lessons to develop new ways to lead our projects to that successful out we rightly desire. 

Stay tuned for more on Writing in this blog along with articles on other areas of interest in the Infrastructure and DevOps arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!

Best Regards


Related Articles

image of certificate for John Mulhall in Hasicorp Terraform Associate earned August 2022

Hashicorp Terraform Exam Experience

Image of Tony Kirtly from Secureworks speaking at FirstConn22

Major Incident Command

image of legal form for Maolte Technical Solutions Limited

Managing Change

image of whiskey tumbler in salutation pose

Where We Belong

CALMS DevOps image

Evolution of DevOps