Requirements Gathering for a Project

One of the key phases on every project is requirements gathering from the users. If the project manager does a bad job gathering the users’ requirements, they’ll get change requests every week for features or deliverables. The users will say things like, “I found some more things that were “missing” from your project plan. If you don’t add them to your plan I will go to my boss.”

These changes add time and costs, make the users unhappy and damage the PM’s credibility. Making changes to a project plan is not a problem. But it is a problem if the necessary changes to the budget and finish date aren’t approved by the project sponsor. The way to avoid this problem is by using good requirements gathering techniques during the project planning phase. Then the user’s change request will be expressed like this, “I want to add to the requirements I gave you during planning. Tell me what the impact is on cost and the completion date.” Good project managers receive this type of change requests. And they are able to handle them so the user is pleased and, as importantly, the sponsor increases the project’s approved budget and duration.  Requirements Gathering Best Practices

Requirements Gathering Examples

Here is the key difference between the two approaches. In the first situation above, the requirements belong to the project manger.  In the second situation, the requirements belong to the user. Let’s look at a simple example to understand what creates that difference.

The goal of the project is to “Reduce Error Rates.” An unskilled project manger would meet with the users and ask what they need to reduce error rates. Then that PM would create a long list of things the users want. The users view the requirements as belonging to the project manager. So they feel free to add to the list each week. It’s like each of the users sat on Santa’s lap and gave him their Christmas wish list.

On the other hand, a skilled project manager would first get the sponsor to define the project scope. It must be stated in measurable terms like, “The error rate on customer orders is less than 1.5%.” Then the PM and the sponsor would break the project scope down into major deliverables. These major deliverables are the responsibility of each of the user managers. An example could be that one of the user managers is accountable for reducing errors in their department from 3% to 1%.

The project manager would meet with each user manager and ask, “What do you need to reduce your departmental error rate to 1.5%?”  One manager might list new systems. Another might need more people. And another might list modifications to the training classes. The project manager would record each manager’s requirements and link them to the project goal of “The error rate on customer orders is less than 1.5%.” In this process, each of the user managers “owns” the requirements they gave to the project manager.  Requirements Gathering by Prototype

[ctct form=”28721″]

Requirements by Prototype

Gathering your project’s requirements by using a prototype can be effective because it is very attractive to the users.  Requirements by prototype consists of planning and then developing a sample deliverable for the users to “play with,” review and modify.  Prototyping takes some pressure off the users.  They don’t need to specify all of the requirements up front, without having evidence that they work.  After the team produces the initial project deliverables, the user/client evaluates the prototype and tells the project team about the prototype’s flaws. Then the team goes back to work to fix those issues. They produce another prototype for the user/client to evaluate, and the cycle goes on.

Project managers use prototyping with certain types of projects. It’s most often used in software development where the cost of making changes to the prototype is not too expensive. They also use prototyping in manufacturing, depending on the cost of each iteration. Prototyping can take a great deal of both the user/client’s and the project team’s time, depending on the number of iterations. The arguments in support of prototyping are that it encourages continuous contact between the user/client and the project team. Fans of prototyping say it produces a higher quality result and a shorter development cycle. On the other hand, prototyping can create a situation where the project team works on the effort forever. That’s because the user’s requirements change every time they look at a prototype.    Requirements Gathering Main Page

Prototype vs Iterativerequirements by prototype

The requirements by prototype process is different from iterative development because we’re only asking for the requirements, not a final deliverable.  We start by talking to the user and making a plan. Then we produce the prototype. Ideally, the user would review the prototype, make changes and then we would produce the final deliverable.  In the real world we’d make another prototype for the user to review and modify.  Producing one prototype after another allows us to develop the final deliverable prototype by prototype.  Depending on the deliverable, prototyping can be very expensive and time consuming. But if a user or client wants to pay for this approach, a good project manager can accomodate them.

Prototype vs Waterfall

Using prototypes is very different from the classic waterfall approach where we finalize the whole plan in a lengthy planning effort, and then produce the deliverable. The waterfall approach is cheaper.  But it requires the client or user to commit to exactly what they want during the planning process.   It also limits the changes the client can make once we begin to execute. The prototyping approach allows for changes during each iteration, if the client will bear the cost.

Get more articles and videos each week

Project Team Ground Rules

Project team ground rules are a necessity. Almost all project teams have frequent meetings and even more frequent communication in various forms. If the project manager doesn’t set ground rules for these meetings and communications, a significant amount of time is lost. Together, the project manager and team identify and formulate the ground rules that members of the team should follow when they interact. These rules cover video conferences, in person-meetings and telephone conferences. The ground rules can cover a wide range of team member and project manager behavior.ground rules

Project Team Ground Rules: Examples

The ground rules may include the “completed staff work” concept. That approach to meetings aims at substantially reducing the amount of time the team members waste when people at the meeting are not ready to discuss the topics. The completed staff work concept is based on an agenda. Anybody can add an item to the agenda. The only requirement is that they distribute materials to all the team members before the meeting. That allows everyone to come ready to discuss the issue. Another rule is that you cannot raise an issue at the meeting that was not on the agenda with preparatory materials distributed. These rules help avoid bad decisions being made when people have not had time to thoroughly consider the issues.

Other ground rules may deal with interpersonal conflict. As an example, a ground rule may prohibit discussing work issues on previous projects. Other rules may bar personal criticisms, (“you’re very stubborn”) versus criticizing behavior (“you would not listen to my side of the problem”).

It is very easy to get carried away with too many ground rules. You don’t want people to have to consult a lengthy document to decide how to handle an interpersonal situation. The ground rules should fit on one side of one piece of paper. Remember, the goal is to avoid wasting time in meetings or making bad decisions because people are  unprepared or rushed to make a decision.

Project Team Ground Rules: Project Meeting Scenario

A status report meeting I participated in some months ago lasted 2 hours. Approximately 20 people attended, including the project team, test leaders, team leaders, PMO staff, etc. The meeting had many elements that are considered best practices. They included the following:

  • all attendees sent the PM their issues before the meeting
  • the agenda was distributed before the meeting
  • no other issues were brought up in the meeting

Long story short, it went something like this. Each person went through the status report covering their work stream, what they did, what they were going to do, issues, risks, decisions to be made, etc. I noticed that after the first 30 minutes, some of the attendees lost interest. After one hour, most were either checking their phone or chatting about something with the person next to them. You can imagine how the situation was after 2 hours.

I share this example to make the point that following what are considered best practices does not mean you are efficient or effective. In the above example, if you calculate 20 people * 2 Hrs = 40 Hrs (40/8 =5PD) of effort for a single status meeting.  One meeting a week adds up to 260PD a year, which is a significant effort.

Project Team Ground Rules: The 30 Minute Meeting

Below is an approach that has worked for me. I call it the 30 minute meeting.

  1. Schedule important meetings early in the day. A meeting is a pit-stop (as in Formula One racing) where all the team members must get the overall picture. It must be kept short and to the point.
  2. The core of a status meeting is the status report. Prepare it beforehand. I like to prepare a presentation vs. a written document.
  3. A picture (or better a chart) shows no more than 1,000 words. The PM must give the bigger picture, showing all relevant charts in perspective. That includes the actual, planned, and forecast.
  4. All topics that are on track don’t need to be discussed one by one. They are only referenced in the status report (preferably in a chart). Include all the details in the appendix for the people who want to read it on their own time.
  5. Deal with topics that need bilateral attention outside the meeting. Time is precious so nobody is allowed to waste it. The PM must ensure the status meeting is not a place for everyone to dump their issues and problems.
  6. Keep it short and keep it clean. Be brave to exclude from the meeting all less relevant content. A short and to the point meeting is too important to be sacrificed for side topics.

Finally, a PM needs to keep the right balance of management overhead and actual work product in their meeting ground rules. My rule of thumb for overhead is not to exceed 10% of the total efforts. This approach to status report meetings works for me. It leaves the team energized, their attention sharp through the entire meeting and minimizes the management overhead.

Get free articles and videos like this every week

Practical Project Methodology

A practical project methodology is a set of instructions and steps for people to follow in doing a project. There is great advantage to the organization from having a methodology which is followed on all projects. This does a couple of things for the organization:
1. Every executive who sponsors projects and everyone who works on projects will have a consistent set of rules to follow. That saves time on every step because you don’t need to figure out how to do it; you don’t need to reinvent the wheel.
2. A methodology allows the organization to control how resources are used on projects. The methodology usually includes a procedure for initiating a project and securing some level of approval for using company personnel and money. Project Methodology Main Page
Those two very important benefits are often not realized because the methodology that is developed in the organization is not practical. A frequent flaw is too many forms, too many meetings and too much wasted time on bureaucratic procedures.  This added level of bureaucracy has project managers asking executives, “Do you want me to do the project or fill out all these damn forms?” The way to avoid this is to have practicing, practical-minded project managers develop the methodology. The goal of the methodology is to standardize things, not make everybody a better project manager.

A practical project methodology and project best practices are a minimum requirement for project success but not the key to success.  The people are the key to success and a practical methodology considers this.  A methodology is most  useful when working on critical projects, or when you need to improve the general health and performance of the organization in running projects.  But too often the methodology does little more than create burdensome paper work.

practical project methodology
Following a project methodology

This practical project methodology is based on my experience and lessons learned from failures.  A  methodology should be simple like “adding eyes and ears to watch your back.”  As trivial as it may sound, it can save the day.

A project is an ad-hoc organization with clear goals and accountability structure. The PM and Sponsor are ultimately accountable and must  leverage the resources the organization has allocated and achieve the specific scope. We have project failure when the accountable individuals don’t have a simple methodology to follow. In many cases it fails from weak scope management which is a result of weak stakeholder management. In other cases it fails from PM’s getting overwhelmed from the tracking activities, managing communication and loosing the big picture (like missing the forest when looking for the tree).

However, I have seen projects where a complex methodology was followed by the book and still failed. It failed because the sponsor and PM failed to gather together a group of high energy, responsible people who could enforce the plan and oversee the daily activities. My experience is that the most important aspect for these people to be effective is the right combination of energy and responsibility. At this task, even someone fresh from university, but with the right biology can be a much better team member than an experienced person. As a closing point, making sure to involve the right persons in regards to the character traits is the first, and maybe most important, step to improve project performance.

Overconfidence in Project Management

Most successful professionals have a great deal of confidence. This is particularly true of project managers.  They have climbed the technical ladder to reach the project manager position and a few successes may have elevated them in the eyes of management above the other project managers.  This can cause overconfidence which is a situation ripe for disaster. A project manager who is overconfident in his/her project strategy, technical solutions, time and cost estimates is dangerous. That overconfidence leads to assuming too many risks at too high a level. A humble project manager is a much better bet for project success. The humble PM doesn’t decide that risk management is unnecessary because he’s a great problem solver and firefighter. That’s just foolish.

Consequences of Overconfidence in Project Management

Overconfidence in project management has lots of consequences some good, some bad. Overconfidence affects a project and their managers in lots of ways:
1. When PMs make commitments on completion dates
2. When team members make estimates for their tasks
3. When engineers commit to making a solution work.
What do I mean when I say overconfidence? Project Manager Skills Main Page

A few days ago, I was having a conversation with a friend who studied Overconfidencepsychology. We touched on overconfidence, an especially interesting topic regarding common human behavior and decision making. It appears that there is scientific consensus documented in hundreds of research studies. They call it the better-than-average effect. The majority of us humans are much more likely to overestimate our level of skills, or be overly optimistic regarding our future, rather than underestimate.
This reminded me of common mistakes in project management. Mistakes mainly related to wrong estimation, overly optimistic assumptions and neglected risk management. As I do not have the research or hard quantitative data, I can share my personal experiences and opinion on how overconfidence can significantly lower the probability of success for project. To be entirely fair, sometimes it can have a positive result in motivating the team toward an above average performance.

Examples of Overconfidence in Project Management

Here are two examples if overconfidence in project management that I will touch on.
The first is a project responsible to deliver a system for managing a lending process. It had an original estimation to finish in 9 months. Instead, it finished after 2 years. Clearly, in the eyes of the sponsor, stakeholders and steering committee, it was labeled a disaster. The worst part was that every time the team reported a status they asked only for 1 more month deadline extension. This presented, in their view, a realistic plan to finalize the scope. They worked an average of 12 hours a day, but the end result was a disappointment. The project for the next years became the benchmark of what could be done wrong. In another country of the same bank with almost the same project scope, they had an estimation of 3 years. They finished 2 months ahead of time and were praised for the achievement.

The second example is a project related to credit risk. The benchmark for projects with a similar scope in other counties was 1.5 years. The local project pulled it together in 7 months. How? Practically without sleeping and keen will to stay to their commitment. This is again an example of overconfidence, yet the team this time succeeded. The project was praised and it became one of their strong assets for promotions and their CV.
Even though, I believe that the more generic effect of overconfidence is the first example, the second is a possible scenario as well. A team can be energized, especially if they are the source of the estimations (bottom-up), to achieve  against-the-odds results.

What can a project manager do to manage these phenomena? First it is important to know that people are subject to unbalanced decisions, or estimations, usually on the upper side. It can be addressed as one part of risk management plan. When applicable, it helps to have industry standards for the resources and duration needed for specific tasks. An example are the benchmarks regarding software development productivity and duration. These benchmarks then compare to the bottom-up estimates. It is normal to expect some degree of deviation, yet if the difference is more than 30%, it is worth digging and understanding a bit deeper.

Apart from the risks it brings, overconfidence may as well be a tool used to comply with external constrains, which require an above-the-average performance. A committed team is more motivated to stay to the commitment. If committed, even when the team is required to deliver above its normal productivity levels, it is more likely to do so.
No cookbook and easy way exists to deal with overconfidence; it is rooted in our being. Yet I believe that acknowledging it and putting triggers and actions in place to mitigate and/or make use of it may became the difference between success and failure.

If you are interested, you can check out an interesting article on the topic: The Overconfidence Problem in Forecasting, NY Times, author: RICHARD H. THALER . Some other researchers are Camerer and Lovallo 1999, Hoelzl and Rustichini 2005, Koszegi 2006, Chuang and Lee 2006.