A lesson of Gathering Requirements

Posted on October 20, 2012 by ThePMJournal

Operational meeting always lasts three hours instead of one. Many times, I had the sensation we fake working (there is always someone late at the meeting or someone is tapping his Facebook app during the meeting). Of course in three hours of conversations, we talk also about serious problems: long term plans, loyalty programs, but all of them remained on the stage of wishes, at least until now. Practically we didn’t managed to sign a contract with a strategic partner and we didn’t manage to sell nothing. Although we are in deep shit, still we are dreaming at “plans will change the world“…

CEO asks me to think in terms of “vision” and “strategy“:

-If the man created iphone, God rest him in peace, wouldn’t have “vision” we won’t be here!

We all eyes and ears to our “spiritual adviser”, The CEO.

-Over one year, partners will pray in their knees to sign a contract with us but we will ignore them! threatens CEO, despite the fact we didn’t manage to sign no important contract.

Then CEO, pointing his index finger to the sky, continued euphoric:

-I can see, one year from now on, how our partners will knock on our door to join us and we will tell them: You didn’t want to join us when I asked you, now we don’t want anymore…

(The truth is that, one year from now, our start-up could be “ashes to ashes, dust to dust“…)

-Gather all the ideas from everybody and let’s make long term plan! In this moment, we are missing an overall vision… I was ordered.

CEO ended the speech with the same sally, repeated over and over at the end of each speech: “Get it done!“, “You lead!“. In the perspective of latest events (parent company failure, contracts lost, etc), this burden has become the target of all jokes of the employees.

“Gathering Requirements” Process (an overall vision)

In the past 8 months meetings, we managed gathering a ton of ideas and requirements. 80% of requirements were questions without answers: “What would you say, if we change the color of the application? Why don’t we make it in a different way?” and 20% requirements similar to this: “Investigate how can we modify our application, so we could sell it. Everything clear, right? Get it done! You lead…”

Before I start presenting the way how requirements are gathered in F-Startup, here you should know how our key-stakeholders look like:

For gathering and filtering requirements of our product and project scope, I draw the following Stakeholders Matrix, in order of their importance:

I begin to collect requirements from all the positive stakeholders starting with first quadrant (those with decision power and big interest to project), then I continued with other quadrants, second, third, etc. When it comes to negative stakeholders, the situation is more complicated. For example, one of the key stakeholder refused to provide his input on some requirements, arguing “I am not paid enough to to this“. So, his requirements being “undefined” were not included into the plan, but I knew at the end of the project, he will certainly want his expectations to be satisfied. Another negative stakeholder provide me contradictory specifications, intentionally, so he could negotiate later the terms of his requirements. These types of stakeholder I consider them “terrorist/kamikaze” type, because they are willing to blow up an entire building only to stop the project… About negative stakeholders, you don’t know what to expect, but make sure you have eyes on your back and carry always a gun!

After long debates, finally I obtained a list with the following requirements:

At the beginning, in the Product Scope there were over one hundred requirements, but more than a half remained “unclassified” or eliminated from the scope because they were either invalid, either unrealistic expectations  (“I want to get rich from our product“), or unwritten requirements (i.e. hidden agenda). In the end, we remained  only with “high-level” requirements (in theory they are called Product Scope Document or equivalent in Agile: themes and epics). From all requirements, only written requirements are part of Product Scope!

Detailed Requirements

After high level requirements, COO told me:

-Now we have the requirements. Start the effort estimation!

Initially I thought he is joking:

-Are you kidding, right? How can I estimate these notes? There are stories told at drunkenness. We should analyse and detailed them before I estimate them.

-You have the specs… why can’t you estimate them?

What is fundamentally wrong in this approach?

The “high-level” specifications (or Epics and Themes) are sometimes so vague, can’t be estimated. Based on a simple analysis, you could reach the conclusion some Epics could be another projects by itself that couldn’t be estimated easily on all aspects: cost, time, resources, etc. Because the details of all the requirements could last indefinitely, it was very useful to start detailing only on a small set of requirements.

What have we detail?

PMBOK tell us detailed requirements, part of Project Scope, are gathered in the Planning stage, after we collect high level specs (based on Project Charter or Product Scope, in Initiating process). Although theory says all details should be gathered early in Planning Process, when is about a project with unclear objective or vague requirements, the detailing could be done even later, in multiple stages (in “waves”). The technique used in this case is called Rolling Wave Planning in PMBoK (project planning in waves as the project proceeds and later details become clearer) and is very similar with “iceberg planning” from Agile. The reason we should not gathered all details, in Planning, is because we are not sure if all the requirements defined now will be relevant in the future (i.e. suppose the company changes his profile in few years or will be closed)… This type of detailing in “in waves” has huge advantages: you gain time detailing only those requirements are important in the next future and this let you start the development earlier, before the entire scope is known. Requirements not important in the next future will remain on the stage of “high level” requirements.

However how do I know what are those requirements truly important?

I was scheduling another meeting with all key-stakeholders, in the same day, just three hours from the meeting we had in the morning, in order to determine what features are important or not. The reaction of COO was:

-What meeting? I thought we understood what need to be done… Where are our estimations?

-Well, I couldn’t do the estimations without knowing priorities.

-Let priorities alone… Please, do first effort estimations. If a feature takes less effort, then it becomes a priority…

Choosing priorities based only on effort (duration, in this case) is an unrealistic approach. It could happen the following scenario: the features take less could be unimportant for the business and their premature implementation could negatively affect the clients expectations. So, priorities should not chosen based only on time, but also on other project constraints (scope, money, resources, quality, risks, customer satisfaction).

CEO refused to attend to the meeting, arguing the meeting was announced in short:

-I can’t to attend. Next time, schedule the meetings sooner… Can’t it be without me?

-I am sorry, it can’t be! Your decision is the most important! I tried to feel him proud.

But despite my insistence, he didn’t accept the invitation. The meetings started. In the meeting room, the Experts group and COO.

-I am sorry I called this meeting in short, but I consider is very important to continue with prioritization of our features. At the end of this meeting, we should have decide together the importance of each features.

COO being the second in command, when CEO was missing, he started to make “the law”:

-What feature is this? I guess everyone agrees is less important, right? Low importance. Next: Very important, low importance, very low. (COO begins frenetic to choose priorities as on Bingo game).

In 5 minutes, COO decided the importance of almost 50% of functionality. Then, suddenly CEO made his appearance. The room turned quietly and things returned to “normal”: after everyone expressed their opinion, CEO decided:

-Very important… Next!

At that time, I asked myself: What kind of meeting is this? The chosen priorities have no justification. At the end of the meeting, I realized I made a big mistake: because the session was called “choosing business priorities”, everyone thought they will decide “priorities” instead of choosing important features from the business point of view. Here are my results:

The list I got was not a list o Priorities, but a list of Business Value/Business Priorities, so in order to establish the Priorities, I have asked the development teams to provide me a rough estimation of the effort needed (balancing cost, time, resources, etc):

Then, based on a benefit cost analysis, I established our priorities (T1, T3, T4, T2). It could be observed T4, even was considered a low priority, from business point of view, become a feature with a higher priority (based on Benefit/Cost Ratio):

What is the conclusion?

If we have a project with vague specification and unclear objectives, the details are gathered in small steps:

1. It starts gathering of partial details (with overview high level  specs) of all features.

2. It is chosen Business Value (or Business Priority) for each feature.

3. It is estimating the Effort of implementation (without a precise estimation).

4. Based on Business Value and Effort, using a Benefit Cost Analysis (or other method) we obtain Priorities list.

5. Based on the above list, we start to gather all the details of the first features (like in Rolling Wave technique).

All the steps could be summarized in a single image:

“Iceberg” planning (only the head of iceberg is known)

Read next: Priorities, a logical choice.

Previous: Master of Puppets.