MISSING

REQUIREMENTS !

WHY ARE SO MANY REQUIREMENTS NOT IDENTIFIED IN

THE PROJECT SOPE ?

THIS IS NOT WHAT WE EXPECTED !

Have you ever wondered why requirements keep popping-up long after requirements collection has been closed? Have you ever been confronted with requirements coming to the surface whilst development activities are steaming ahead? Or do you recognize the situation that users tell have you very close to the delivery deadline that the project result is not really what they expected and that it does not live-up to the really needed requirements? Probably your project is suffering from the “assumed evidents” problem during its requirements collection and definition activities. In this project management article, I will explain you some of the pitfalls when requirements are defined at the beginning of the project. I will conclude with four specific tricks that will keep you away from the “danger zone”.

INVOLVING THE MOST

EXPERIENCED AND BEST PEOPLE

IN REQUIREMENTS COLLECTION ?

In a lot of cases, independent whether you are working with a waterfall project approach or an agile project approach, as a project manager, you should organize the collection of requirements to build up your project scope or your agile backlog. And often, if not always, that requires bringing people together. Because the project is considered as important and the subject as complex, we rely on the most experienced, most competent people and specialists. And if we get them assigned to our project and they are finally sitting around the table, we feel ourselves lucky and praised. We even believe, because management makes these skillful and important people free for the project, that it really shows the commitment of the organization to our project. Let’s be honest, if senior management assigns the head of accounting to our project with an objective to implement the new accounting software, and that for several hours to provide the required input to the project, that can only signify a huge commitment of that company or organization. That the head of accounting’s day-to-day work is not really reduced, making him or her doing the project tasks “on top of” or “between the soup and the potatoes” is most of the time not mentioned. Nevertheless, we got assigned all that experience, together with the best ICT-consultants, so it can’t go wrong! Right? Not! It is exactly having all that experience and expertise, and the best of the best, that is one of the factors leading to forgetting requirements during the requirements collection process. And no, I am not promoting that from now on, we should work with mediocre project team members, as a solution to our problem. But I do want to raise your attention to the fact that we should be well aware of the flaws of working with these experts. We should understand the dynamic of people’s thinking and behaviors in their relation to the requirements. There is a dynamic between realizing requirements, fulfilling the needs of the expert project stakeholders and overall project satisfaction.

IN THE END IT IS ALL ABOUT

CREATING STAKEHOLDER

SATISFACTION !

During a project, once defined, you can, in extremism, do two things with a requirement: 1. You can realize the requirement and therefore fulfill the need of the (end-)user, or 2. You do not realize the requirements, and in consequence not fulfill the user’s need. I leave for now the fact that you can also partially realize the requirements… Do note that partially realizing requirements is considered by a lot of us as negative, as in “it is better than having nothing, but it is still not what we have asked for.” Realizing requirements and fulfilling needs of project stakeholders is also directly related to the satisfaction levels of those project stakeholders, being the users, project sponsor, senior management, clients of the project, etc. If all goes well, and we fulfill the needs of the project stakeholders by realizing the requirements, because of that dynamic and direct link, it is acceptable to assume that the satisfaction level will increase. Equally, when requirements are not realized, the stakeholders’ satisfaction levels will decrease and ultimately can lead to full dissatisfaction. Therefore, any form of partial realization will lead to a certain increase or decrease of the satisfaction level. Seen on the project level or the full scope level, we could also argue that we have the option to realize all stated requirements, none of them or a certain percentage of sub-set of them. This decision will equally lead to fulfillment of the needs and therefore project stakeholder satisfaction or dissatisfaction. For the sake of simplicity and the discussion let us assume that realizing one requirement will lead to an increase of the satisfaction level with one point, whatever the latter might mean. I do understand that some requirements are more important than others and that a kind of weighing system should be considered, but that would leads us too far to make the point. Also the consideration of overall project stakeholder satisfaction is more complex than the dynamic explained above. For example, realizing a certain requirement might make senior management really happy, but will make the workforce rather unhappy, but still for the project, the overall satisfaction level might increase… So, the dynamic is not as linear as the image below may appear. But as mentioned above, we’ll keep it that way for the sake of explanation.

CAN THE DYNAMIC BE

INFLUENCED ?

As already indicated above, from itself, the relation between fulfilling needs and stakeholder satisfaction is not linear and there are many factors that influence the steepness of the relation line. But we should understand as well, that decision making during the project might have a direct impact on the incline as well. We should understand that we can define different “kinds” of requirements. We like to refer, in this context at least, to the normal requirements. It are those requirements that follow our linear relation between needs fulfillment and stakeholder satisfaction. In other words, these requirements will follow the dynamic: the more requirements are realized, the more needs are fulfilled, the more stakeholder satisfaction is realized, and of course the other way around in case of less realized requirements. These “normal” requirements are always explained and discussed in a requirements collection meeting. They will be put on the table, for you and your project team of specialists (e.g. Business Analyst) to pick them up and to assure they are incorporated in the design of the project product. But more often than wanted, during these requirements collection meetings, the stakeholders will come-up with requirements that they consider as something they really want, but often these requirements are just nice to haves. Often it are the requirements that were provided during a sales pitch and that people convinced to buy the solution. Such requirements are in this context referred to as the “exciting” requirements and when realized, the satisfaction incline will be more steep. You could argue, in a simple way, that realizing one such exciting requirement will lead to two satisfaction points increase. Realizing such requirement can therefore be compensation for another normal requirement which has not been realized. The exciting requirements are always mentioned during the requirements collection process. It is only a matter of capturing these requirements, documenting them correctly and making sure you can realize some of them to get your satisfaction levels boosting! It is clear that these requirements will not be forgotten about!

THE REQUIREMENTS DANGER

ZONE

Fully understanding the dynamic between realizing requirements and project stakeholder satisfaction is also be aware that there is a danger zone, or in other words, that not realizing requirements can lead to stakeholder dissatisfaction; the reason why we have to try to capture all requirements. Capturing normal and exciting requirements should be fairly easy as they will be mentioned when your interviewing and questioning techniques are organized your skillful specialists-project team members. You should be more afraid of those requirements that are not automatically put on the table. These are the so called “assumed evident” requirements. As the name says: there are a lot of requirements that are assumed evident by specialists. Specialists will not ask about them as they consider it a silly or stupid question and contributors will not talk about it because they believe everybody knows about them and it would be foolish to talk about them. Just imagine one of my personal stories… I was involved in an ICT project, with the objective to replace an existing accounting software with the financial module of an ERP package that was implemented at that moment in time. For this mission, we brought the most experienced accountants and ERP consultants around the table to discuss and collect the requirements. All normal requirements, like the desired account receivable functionalities, the account payable functionalities, functionalities related to the general ledger, etc. were listed and documented. I even remember the documentation of one of the exciting requirements: a visual dashboard on the aging of client invoices that allowed the account receivable specialist to easily identify for which clients money collection and claims actions needed to be undertaken. In that project we were able to realize most of the documented requirements including the exciting aging dashboard, but our project client was not satisfied. Our project client argued that he couldn’t understand why the human resource salary administration functionalities were not fully implemented in the final ERP setup. And that they had to keep working with the existing old and user-unfriendly salary administration package. “Every accountant in this organization knows that our human resource salary administration is so closely linked with our financial administration, that it is really not understandable that both administrations have to perform their work in a different software, especially when an ERP system is implemented in our organization.”, he argued. Our project manager reacted, perhaps wrongly: “I am very sorry, but this was not mentioned during the requirements collection meetings, and this requirements was therefore not documented. By consequence it was not considered as part of the scope of this project.” He further explained that: “Whilst it might be a common practice in this company to have the human resources and financial administrations tied in so closely, it is certainly not a given, for other companies”. The ICT project manager also added that he really didn’t saw the problem as the link was assured anyway via the interface that was realized between the old human resources administration software and the new ERP financial modules. Above is a typical case of the “assumed evident” requirements… The accounting manager finds the close link between the two administrations so “evident”, so “basic” that it is even not worthwhile to talk about it… Everybody within the company knows this! He would even feel and be considered foolish when talking about such evident requirements. His colleagues and probably the “other” experts around the table would feel treated un- respectful as if they wouldn’t know about that link. At the same time, the accountant makes the mistake of generalizing his opinion by believing that “Everybody” should know that. He makes the error of projecting his own thinking and mindset, his own model of the world, in a one-to-one projection to the other parties. But also they have another model of the world… So did the external ICT project manager and his team where I belonged to. In other organizations, links between different software systems are made with the realization of a simple interface. For such external team, that way of linking is “so evident” that it does not have to be discussed… therefore making the same mistake as the head of accounting. And there you have it… important requirements are forgotten, because all parties involved perceive this requirement as evident it does not have to be discussed. One thing is for sure, the assumed evident requirements will not be mentioned automatically… they need to be sought after! Or they will reveal themselves at moments that you, as a project manager, will rather not like… Not realizing the assumed evidents will have a similar effect as the exciting requirements, but in the other way. They will decrease the client satisfaction and often in a very steep decline as the client-stakeholders “do not understand” and are often disappointed.

FOUR TRICKS TO AVOID THE

DANGER ZONE !

What can you do to avoid as much as possible missing the assumed evident requirements? Trick 1. Include junior team members around the table Whilst we like to work with the best people and specialists available, try also to consider less experienced, and even better, junior people during your requirements collection. Junior people are still allowed to ask the so called “stupid” questions. And they will do because their experience level is still lower so that no single requirement is, for them at least, an evident requirement. Now, do not misunderstand me here.. there are no stupid questions, but it is clear that when a junior person would ask such a question related to an “evident” requirement, the experts find it normal that a person with little experience asks such a question. Answering that question will even be seen as positive, as we will all be contributing to the personal development of our junior colleague! Trick 2. Perform prototyping When prototypes have been shown in my previous example, an interface between the accounting and human resources administration software would have been shown, and would certainly have led to reactions of the accounting stakeholders before the start of realization and with still ample time to make the necessary corrections or to organize the scope-budget discussions. But at least before a project product was delivered with a dissatisfying result. So, assuring to show prototypes as soon as possible, will help to avoid requirements getting forgotten. In ICT projects, prototyping can go from designing the process flows and discussing requirements around the flow charts, using role playing techniques, designing “mock-up” screens, etc. For construction projects, prototyping might be maquettes, pre-render 3D photo’s, virtual reality experiences, etc. We should never forget that there is the attention point that people will get new ideas as they see things… They are not necessarily new ideas, they might just be non- expressed assumed evident requirements… Trick 3. Choose an agile project approach Choosing for an agile approach can benefit your project when you fear for a lot of assumed evident requirements. It is closely related to the prototyping trick as the minimum viable products will actually serve as a kind of prototype which can be commented on. Potentially newly discovered or assumed evident requirements can be defined and logged onto the backlog as they pop- up, and they can eventually be considered for realization in one of the future sprints. Trick 4. Apply Neuro-Linguistic Programming (NLP) techniques during requirements collection And as a last tip or advise, I can truly recommend you to become, as a project manager, skilled in coaching skills. With obtaining coaching skills you will learn to take into account the principles of “the model of the world”. Also becoming more skilled in Neuro-Linguistic Programming, NLP, techniques is very useful in order to be able to build rapport between the stakeholders that need to provide input on the requirements and the specialist project team members. The NLP techniques will also allow you to build trust between the stakeholders and automatically they will become more “open” and probably will lesser be concerned about saying something “foolish” as being the expert. Or in other words they will automatically reveal more requirements otherwise assumed to be evident. NLP will also help you with asking the right questions, so you can poke in an non aggressive way to the requirements that otherwise only will be discovered when it’s too late… The Project Management Institute (PMI) and the Project Management Body of Knowledge (PMBOK) - guide are registered trademarks and copyrighted. You can find more information on the website: www.pmi.org.

ABOUT THE AUTHOR

Steven GOEMAN is a certified project management professional and a licensed Master of Neurolinguistic Programming with more than 20 years of project (management) experience. He is the creative mind behind the renowned brand “The Project Management Mentor”, enabling him to share his expertise on portfolio management, program management and project management as an empathic project management coach and project management mentor. Steven founded GAPS BV (https://www.gaps.be) in 2005 from which he successfully assisted many individuals and organizations with project management related mentoring, coaching and consulting services. How to reference this article: Goeman, S. (2021, 01 June). Missing Requirements. GAPS BV. https://www.gaps.be/Mentor/pmart007- requirementsmissing.htm .