Project Management and Information Management professional, Liselle Ramcharan-Briscoe, continues the data adventure by sharing with us how best to prepare when executing projects, and to better position ourselves and our team for their successful completion.
There is a song that goes, “Do you know where you’re going to, do you like the things that life is showing you, where are you going to? Do you know?” For your project, your requirements tell you where you are going to.
Learning #2: Spend time on your requirements
The dictionary defines “requirement” as “a thing that is wanted or needed”. You will find that most development methodologies emphasize the importance of spending time on the requirements – the actual needs of your project, whether building software using the Software Development Life Cycle, as shown in Figure 1, or developing the Business Requirement Document for your project.
You will find variations of the model in Figure 1, but this is the one I “grew up with”, that emphasises requirements as the first step. I was even shown a pyramid version of this model with the same steps, but going from large to small, from Requirements to Testing, to emphasize that the more time that you spend on your requirements, the less time you spend on the other phases. Depending on the unknowns and the complexity of your system landscape, it may not be considerably less time spent, but it certainly becomes an easier process.
Figure 1: Software Life Cycle (Source: L Ramcharan-Briscoe)
Time effectively spent on developing the requirements allows for a certain level of agility in making changes. There was a project that I worked on where our requirements would have cost 4 times the amount that the business had budgeted for it. Creating budgets before understanding our requirements is another discussion, but that often can be the reality of a project. The good part of the story is that we had spent so much time outlining the requirements, that it was very easy to identify the areas that we could eliminate.
In my last article, I mentioned the importance of knowing who my stakeholders are, and this is one of the many areas in your project where knowing who they are becomes important. For this project, approving changes to the requirements was very simple because our requirements were clearly defined and we knew which stakeholders would be affected by the changes made. We had already spent about 4 months on the project and we were able to approve the changes in less than 2 weeks.
Figure 2: Project Phases (Source: L Ramcharan-Briscoe)
Figure 2 shows the project development methodology as defined by the Project Management Institute (PMI) when considering a project. These project phases are high-level and can even be replicated within the stages of your project. The PMI, for the initiate process, defines the most important activities as “…identifying and defining business requirements, outcomes, and success criteria; defining business justification…”. These should be your starting activities to lead to a successful implementation.
Building Requirements for Green-Field Projects
A green-field project is one in which you will be charting a course that has never been traveled before by your business, or by any other business for that matter – if you consider an innovation (a brand-new idea). There are no completed projects that exist, where you can benefit from the approach used or the lessons learned.
For this type of project, it is even more important that you spend the time building your requirements. You have to capture all that you understand at that point in time and provide as much of an outline as possible. You need to list your assumptions, risks, plus what is in and out of scope for the project.
What you will find for a green-field project is that there are assumptions that you will make that may be found to be invalid or not applicable as you learn more about what you are trying to innovate. But in properly outlining what you do understand and potentially debunking them, what you have captured become starting points in outlining what the requirements actually need to be, and what changes need to be made.
Parting thoughts
When you know where you are, if the winds of change come your way, it makes it easier to understand the impact the winds could have, and how you may need to re-chart your course. This does not always make it easy, but it certainly supports a more systematic approach to solving your problems and moving forward with your project. Requirements, either fully developed or that allow you to frame a good foundation, definitely help you know where you are going to, and eventually can be used to determine whether you have reached your final destination.
Image credit: Eluj (Pixabay)
Excellent insights.
Very “Michele-oriented” in terms of presenting in the very simplest form, such that even those of us, like me, who are less tech-savvy follow without a hitch. ( Maybe it’s a Caribbean attribute. ) For some reason I didn’t notice the previous part, which I have just read too.
I notice, though, that term “project” being consistently used throughout the two-part article. I believe the insights drawn herein could be a template for all “products”, any undertaking for that matter.
Thank you for your feedback Kamutula!
It is really important that all ICT Pulse readers can understand the articles, so your feedback is very welcome!
Also Kamutula, you are so right about the ability to apply this template to any undertaking. When you review the definition of a project, it is creating a unique product, service or result. So it is an approach that can be applied in different areas.
Couldn’t agree more. Absolutely!
That’s so great! Thanks again Kamutula!
The information and insight here is fantastic. Thank you for explaining in such depth!