Posted on

Requirements Gathering Blunders and Best Practices

Many project failures are caused by poor requirements gathering techniques. These blunders cause three separate problems for the project and each one can increase the project’s cost and duration and lower the users’ or clients’ satisfaction. Every week stakeholders submit requests for new or modified requirements because

  • The project deliverables are not meeting their needs
  • The project manager disagrees with stakeholders about whether certain features and functionality are included in the project’s scope of work.
Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Sometimes these problems are minor annoyances. Other times they’re expensive and hard to correct. Here are the classic errors you should not make when gathering stakeholders’ requirements. Requirements Main Page

Requirements Gathering Blunder #1: Secret Requirements Meetings

Some project managers think that the assembly of project requirements and specifications should be done in secret so there is no interference from users. They believe the requirements gathering process is more efficient when it’s done by technical experts, not the users or the clients. Their reasoning is that the users/clients don’t know anything about the technology at the heart of the project. So why waste time explaining it to them? The PM and technical experts will develop the requirements quickly and efficiently and then explain the results of their work to the users/client. This thinking is often based on war stories of previous battles over requirements and project deliverables with the same users/clients. The attendees at the secret requirements meetings also want to avoid listening and learning about the users/clients’ business requirements. They hope to apply their technical expertise very narrowly and give the users/clients an elegant technical solution.

These secret requirements meetings sometimes get the active support of executives who want to start work quickly and not waste a lot of time on meetings and paperwork. They also don’t want to give the users/clients control of the project by letting them specify the requirements and deliverables.

The consequence of this approach is a great deal of conflict and, most importantly, a lot of wasted time and money. The project team will undoubtedly produce deliverables that don’t meet the users/clients’ needs or lead to improvement in performance. Unfortunately, this is a downward spiral that organizations often repeat.

Requirements Gathering Blunder #2: Requirements are Just Technical Specifications 

In the second blunder, the project team experts produce a complex list of requirements and specifications that the user/client is asked to sign off on and approve. For some odd reason, the project manager believes this process will protect them from criticism if the user is unhappy with the project deliverables. In the real world, the conversations go something like this:

Dissatisfied User: “These deliverables are not giving us what we told you we needed! They do not meet the needs of our business. We told you what we wanted and you have not given it to us. This crap is useless!”

Project Manager: “But you signed off on the technical specifications and requirements that we gave you. I have a document right here and that’s what we delivered.”

Dissatisfied user: “We had absolutely no idea what that technical gobbledygook meant. We told you what we needed to improve customer service and you have not given us the tools we need.”

Project manager: “I have the signed document right here.”

Dissatisfied user: “Good.  You can show it to my boss when I tell him about all the time and money you’ve wasted turning out garbage.”

The advantage the PM perceives from compiling the list of requirements and technical specifications is that it saves the project manager and team from listening to and understanding the stakeholders business and the business problems they want to solve. Obviously, that is not an advantage. Project managers need to aim the project deliverables at the customer’s business needs, not at a sheet of technical specifications. Unfortunately, project managers often combine blunder #2 with blunder #1.  Then the projects resemble the trench warfare of World War I.

Requirements Gathering Blunder #3: Let’s Make Up a Shopping List

This blunder is friendlier and happier, at least initially, than the preceding choices. But the project result is similar. These blundering project managers approach requirements gathering as if they were making up a shopping list. They go around and ask the stakeholders and other people what they want, then add it to the list. Several bad things happen with this approach. First, they tend to miss requirements and find out they’re missing after they have started work.  That causes delays. Second, people add things that may be good ideas but aren’t needed to produce the scope.  That wastes time and money. Third, people get in the habit of adding things to the project without justification. And that never stops, even after the PM has begun to execute the project plan.

So the PM gets many change requests people expect him to add.  They’re disappointed if they are not. The PM must do a good job limiting what is included in the project plan based on a clearly defined scope. Overruns are the result when they don’t.  If people think they can add things to the project plan whenever they wish, the project will suffer from scope creep. This means its duration and budget will grow every week. That’s when the stakeholders and other people become unhappy.

Requirements Gathering Best Practice: Prototyping

Another way to gather requirements is by prototyping, which may or may not be a blunder.  With this technique, the project team does some requirements gathering, then goes to work, and produces the initial project deliverables. Then the user/client evaluates the prototype and tells the project team about the prototype’s flaws. The team goes back to work to fix those issues. Then 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. Proponents say this 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. More on Prototyping

Requirements Gathering Best Practices

The right way to handle requirements gathering is to have a crystal-clear scope of the project deliverable and the major deliverables that lead to it. Each of these deliverables is defined with an acceptance criteria so you are not dealing with a vague “to do” list. The entire requirements gathering process should be constrained by these criteria which are objectively measurable. Then the user/client justifies their requirements by showing the PM why they are necessary to produce the specified deliverables. If a stakeholder can’t link a requirement to a deliverable, it’s not included it in the project plan.

Let’s look at an example. This company has lots of complaints about their service. Many are tied to the fact that 20% of the customers have to call back repeatedly to get their problem resolved. So you will start by working with the project sponsor to define the acceptance criteria for improvements in the company’s telephone and web-based customer service process. You come up with acceptance criteria for the scope which is “Fewer than 3% of customers have to contact us a second time about the same problem.”

Next you work with the sponsor & senior stakeholders to detail the high level deliverables that are required to move the company from where it is now to the scope definition. That is, to go from 20% of the customers to fewer than 3% of the customers have to call back a second time about the same problem. Those high-level deliverables are:

  • Customer service system provides 18 months of customer transaction and complaint history in less than five seconds
  • Customer service cubicles have an average peak noise level of 72 dB
  • 95% of the customer service reps can answer the top 30 inquiries in less than 45 seconds
  • Customer service hourly staffing creates maximum workloads of 85% of capacity.

The above acceptance criteria give you the tools to constrain the requirements gathering. You link every requirement with one of those major deliverables or the lower level deliverables that support it. You keep track of who requests each deliverable and the performance commitment they made.

You work on requirements gathering at the beginning of your project planning phase.  The requirements are necessary for many other project management tasks. You can gather your project requirements very simply or have a much more elaborate requirements process where you track the originator of each requirement and tie it to their performance commitments.

A very common mistake when gathering requirements is to treat the process as simply making a list of everything everybody wants. This tends to keep people happy because they can add anything they wish to the project. However, you will suffer the consequences of stakeholders adding additional requirements every week. This is the classic form of scope creep where you continue to add new features, bells and whistles to the project. This process also substantially increases the project failure rate. That’s because you usually will not get additional time or resources to fulfill those requirements. So the project will be late and over budget.

Requirements Gathering: Step-by-Step

  1. Immediately after the sponsor approves the scope, you use the information about the identified stakeholders to conduct initial requirements gathering meetings.
  2. You meet with the stakeholders to discuss their requirements for producing the major deliverables of the project. You are not compiling a wish list. Instead, the discussion focuses on each of the major deliverables and what is required to produce them.
  3. You put every suggested requirement through a test of whether it is necessary to produce one of the project’s deliverables. If the requirement is a good idea, but not necessary to achieve the project’s scope, it is not included.
  4. You meet with as many stakeholders as possible with the intent of unearthing all potential requirements. Many of these requirements will not be included in the project plan. However, it is good to identify them during the beginning of the planning process rather than finding out about them late in the project.
  5. For every requirement that is included in the project plan, you complete the requirements register, which documents the individual who is accountable for the requirement. This documentation maintains traceability back to the originator of every requirement in the plan.
  6. When you and sponsor have considered all of the requirements and either accepted or rejected them, you and team can proceed to the development of the work breakdown structure.

You can learn how to gather and manage project requirements in our customized, online courses. You work individually with your instructor and have as many phone calls and video conferences as you need. The Project Management Basics course, #101, teaches you a step-by-step process and how to use MS Project® software to make your job easier. We also offer this Basics course for IT, construction, healthcare and consulting project managers.

At the beginning, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing,  or construction, or healthcare, or consulting.  That way your case studies and project plans, schedules and presentations will fit your desired specialty.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management

 

Posted on

Project Plan in 5 Steps

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

You can produce an excellent project plan that can fit on one side of one piece of paper and take less than an hour to create. It will be suitable for 90% of the projects that most organization do. The key to making this work is for you and the project sponsor to play your roles properly. The project sponsor (that’s the boss, executive or customer who wants the project done) has to define the business result that the project must produce. That business result is the scope of the project and it has to be a metric. The scope must have acceptance criteria that define success in objective, measurable terms. If the sponsor prefers to “plan as we go,” and “stay flexible so we can adjust,” they are not fulfilling their role on the project. It would be foolish to start work on the project without knowing where you need to be at the end.   Main Project Planning Page

Your role as the project manager is to get the sponsor to tell you the acceptance criteria-type of scope definition. Then you and the sponsor break the scope down into the major deliverables the project has to produce. These deliverables the stepping stones for how the project will move from where it is now to the end result the sponsor defined. You are not doing your job if you start work before you have a clearly defined scope with major deliverables. Let’s look at the steps you need to follow.

Project Plan Step 1 – Defining the Scope

Defining the scope involves gaining agreement on the metric that the sponsor (the boss, executive or customer) will use to measure the end result of the project. Project planSponsor who have a successful track record for initiating projects know that you (the project manager) need a clear definition of the project scope that includes a success metric. If the sponsor doesn’t know how to play his or her role, anonymously send them a link to this article. You don’t want your project to fail because the sponsor has a failing record on their projects.

Once you have that success metric, you can create the project plans and schedules rather easily. The difficulty comes when people try to skip this first step or when the sponsor doesn’t know how (or is unwilling) to define the project’s success. Without that scope metric, the rest of the project pieces are useless. Here’s an example of a small project to illustrate how this is done.

A project manager gets a phone call from a project sponsor who says, “I’d like you to run a project for me to deal with our problems getting office supplies out of the warehouse.”

The project manager goes to the sponsor’s office and during the discussion, asks open-ended questions aimed at defining the scope. It’s very possible that the sponsor has started the conversation about the project without having a clear picture of the end result they want. The project manager has to ask questions which help the sponsor define the project’s end result. The project manager asks how performance of the warehouse will be different after the project is complete. The sponsor says, “We can’t run out of supplies so often; we have to reduce the number of these stock-outs. And it shouldn’t take people as long to find what they need.” The project manager should follow up with questions like, “How often do we run out of supplies now?  What’s an acceptable number of stock-outs each month?” The project manager might also ask, “How long does it currently take to find supply items and how long should it take?”

That’s a good example of the project manager asking polite and respectful questions in an attempt to get the sponsor to be specific about the project’s scope. Let’s say the sponsor says people should be able to find the supply they want in less than 120 seconds 90% of the time. That is a crystal clear metric or acceptance criteria for the project scope.

Project Plan Step 2 – Breaking Down the Scope into Major Deliverables

With the scope defined as a metric which the warehouse project must produce, the project manager will work with the sponsor to break that scope into 4 to 7 major, high-level deliverables. They will lead from where the warehouse performance is now to the end result the sponsor wants. The PM may talk to people in the warehouse to find out why it to take so long for people to find the supplies they need. The PM may also ask the warehouse staff for their ideas about how to reduce the time needed to get a supply. The project manager may come back to the sponsor with some suggestions based on this fact-finding process. They may suggest the following high-level deliverables:
1. Increase the lighting in the warehouse to an average of 65 lumens
2. Track the location of all supply items with 95% accuracy on a commercial PC inventory system. The system cost should not exceed $500.
3. Discard any supply items in the inventory that have not been used in the last four years.
4. Redesign the inventory layout so the most frequently utilized supplies can be retrieved in less than 30 seconds.
5. Distribute new procedures for using the supply warehouse to all employees.

Each of those high-level deliverables has an acceptance criteria that can be objectively measured. The project manager reviews the deliverables with the project sponsor. The sponsor may change or adjust any of the deliverable’s metrics to fit his/her assessment of the situation. When the sponsor signs off on the scope and the high-level deliverables that will lead to it, the project manager has a strong start on the project plan and can move on to the planning details. The key point here is that the sponsor and project manager worked top-down; starting from the end result down to the contributing deliverables that will help them get there.

Project Plan Step 3 – Breaking Down the Major Deliverables

The next step is for the project manager to continue to break down those major deliverables into smaller deliverables. The lowest level of deliverables should be suitable for assigning to an individual. These assignments should also be measured deliverables so the team members know what is expected of them (what they must produce) before they start work. These deliverables will become tasks in the work breakdown structure (WBS).  They are also the basis for estimating the amount of work, cost and duration of each deliverable.

Project Plan Step 4 – Estimating

Once this breakdown into smaller deliverables is complete, the project manager has an assignment for each team member. The next step is to meet with the people accountable for producing each of those deliverables. Each of the tasks (the lowest level deliverables in the work breakdown structure) will have an estimate of the amount of work and  the duration. The project manager engages the team members in this estimation process. Involving each team member in this part of the process produces more accurate estimates. The team members also become more committed to producing their deliverables in the estimated amount of time. The PM will enter this data into project management software to create the schedule and budget. Using project management software saves project managers a great deal of time. Software options include Microsoft Project and several low cost or free scheduling applications that are available on the web. Any of those are suitable, especially for a small project.The project manager  will track each task’s actual work and duration against the plan.

Project Plan Step 5 – Final Approval By the Sponsor

The last step in developing the project plan is to secure the sponsor’s final approval on the project scope, major deliverables, budget and the planned duration of the work. With that approval, the project plan is finished and the project manager can begin work.

At the beginning of your course, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing,  or construction, or healthcare, or consulting.  That way your case studies and project plans, schedules and presentations will fit your desired specialty.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management
Posted on

New Product Launch

You settled  down at a table in the company cafeteria with status reports on three of the projects in the program you were managing. You decided to start with the most problematic of your projects and opened that folder, managing to remove the staple with a knife without stabbing yourself. At a neighboring table, people from sales, marketing, production, engineering and accounting were having an intense, heated discussion. You knew all the managers involved and you’d had each of them as a stakeholder on more than one of your projects. You had at least a productive working relationships with new product launchall of them and two were your close friends.

Join a New Product Launch Meeting

One of the friends spotted you and waved at you to join them. As you took a seat you said, “From the gaiety, I would say you’re planning the holiday parties. Am I right?”
Your friend said, “I don’t make jokes at your project planning meetings. Our new product launch session is every bit as divisive.” Your friend looked around the group, held up his hands to all of them, and said, “I’m not trying to score debating points. I’m just trying to summarize everybody’s position on the new product launch.”
The rest of the group nodded but watched your friend warily.
“Okay,” he said, “my friends from accounting think this new product will lose money. They don’t think we can cover the fixed costs in the first two years. My colleagues from sales and marketing take issue with that. They say this new product could be a home run for the organization. The production managers think the new product is too complex to manufacture with a low defect rate. They are concerned that a high defect rate will cause this product to fail. Warehousing and shipping managers think the transportation costs are going to go through the roof because the salespeople want to promise 24 hour delivery.
You listened carefully and nodded at each of the managers as their position was stated.
Your friend turned to you and said, “Pretend this is a project. How would you address this? What do you call it, stakeholder conflict?”  Project Planning Main Page

New Product Launch as a Project

You laughed and said, “What you have here is a project; I don’t need to pretend it’s one. But it’s a project without a defined scope. The scope is what the product will deliver to the organization; its goal. You’re arguing about various deliverables without any framework to define them. Can I ask a couple of questions?”
All the people at the table looked around a bit uncomfortably and then nodded.
“Okay. Am I correct that the goal of this new project is to generate a positive cash flow for the organization?”
Everyone nodded and a few made faces at the obvious statement.
You continued, “How much cash flow do you need to generate in each of the first five years for this project to be a success?”
A manager from sales said, “That depends on how many units we sell.”
You smiled and asked, “How many units are you committed to selling in each of the next five years.”
He replied, “That depends on the price and the features we can offer our customers. That’s the way sales works.”
“Humor me,” you said. “Tell me how many units you can sell if the product contains a specific set of features and a specific production cost.”
The sales manager shook his head angrily, “You’re asking me to go way out on a limb here.”
You smiled and said, “Well eventually you have to commit to how many units you can sell. That allows everybody else to plan on how many units they have to produce and ship.”
The irritated sales manager looked at you and said, “That’s not how marketing & sales works. We sell as many as we can and everybody else has to adapt.”
There were loud groans from production, engineering, accounting, shipping and warehousing.
“It seems to me,” you said, “that there is some disagreement with that approach. I can see how the volume of your sales is going to have a drastic impact on these other parts of the organization. So it’s reasonable that they want to know what sales level to prepare for.”
The sales manager said, “You don’t understand. This is not project management. We can’t specify in advance how many units we’re going to sell because the market is far too turbulent. And we can’t anticipate all the actions of our competitors.”
“You make your point eloquently,” I replied, “but I’d be surprised if good product development procedures let the marketing and sales people off the hook on hitting a sales target.  Having that data and your commitment to it is the only way to start this new product launch. You don’t have to consider it a project but you must follow certain procedures. Like any business person, you come up with an idea for a new product that you think makes sense for the market. That’s what we call a business case. In that document, you justify this product by making commitments to the following:
  • the number of units you can sell
  • the profits
  • the investment
  • the people resources it requires.

That’s what the executives look at decide whether to approve or disapprove this new product. They’ve got to know it makes sense financially, operationally, and in terns of capacity and human resources. I’d imagine, just like in project management, there are other new product ideas or other investments that the executives have to weigh versus your new product.”

The accountants started clapping first, then the operations manager said, “You mean we’d be able to plan production levels based on a sales forecast?”

You nodded at all of them and said, “Right. This is the project management world. New project launches aren’t begun without first being justified. Most importantly, the people who want the project need to make commitments to the benefits the project will produce. They have “skin in the game.” That’s what makes the business case process so worthwhile. Once you get agreement on the scope of the new product (the project), I’d be happy to help you break it down into the production costs, delivery costs, personnel costs and so on. All of them will be part of your network of product deliverables.”

You looked around the table at their approving faces.

Posted on

Project Requirements Video

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Project Requirements: The Key to Stakeholder Management, Scope Control & Change Requests

Managing project requirements builds the foundation for:

  • Effective scope and change control
  • Strong support from stakeholders and users
  • Finishing your project without last-minute requirements surprises.

Stakeholders are the principal focus of managing project requirements. You must continuously try to identify new stakeholders so you can process their requirements and either include or exclude them from the project. That process determines the stakeholders’ enthusiasm  and support for the project.  You obviously can’t include every requirement that your stakeholders think of. But if you identify your stakeholders early and their requirements that are necessary for the project, you take a big step toward avoiding those very expensive last-minute requirements. You know what I mean; they’re the unidentified requirements that leap out of the bushes late in the project and surprise you. They often delay the completion date and bust the budget. Late arriving requirements can cost up to 100 times what they would have cost if you had discovered them during project initiation. Requirements Gathering Blunders

 

Project Requirements & Expectations

When you guide your stakeholders through the process of identifying their requirements and quantifying the acceptance criteria for each requirement, you are “training” them for your scope control process. Once you’ve documented the requirements, you guide them through the process of evaluating whether that particular requirement is necessary to deliver the project scope the sponsor wants. If the scope does not need that requirement, it doesn’t get added to the project. While the stakeholder may be disappointed, they have had their opportunity to submit requirements and have participated in the evaluation process. Once you’ve begun to execute the project, new requirements or changes to the project scope will go through the exact same process. So you’re training the stakeholders that you’re not going to add every new requirement they come up with. In many organizations, stakeholders are used to being able to add requirements whenever they wish. The requirement evaluation process is of particular value in those environments. Collecting Requirements 

Gathering requirements for your project does not involve making a long list of what everybody wants. Project managers often use that technique because it makes the users and stakeholders happy… in the beginning. The project manager can be like Santa with all the stakeholders coming to sit on Santa’s lap and describe what they want. They will also list expenditures that are good ideas/”nice to haves” or the things they didn’t get in their latest budget. The major flaw of this Santa Claus technique is that it doesn’t limit the requirements to what is necessary to produce the project scope. The unfortunate consequence is that you will be doomed to repeat it every week during the life of the project as people want to add more features and functionality to the project. Prototyping Project Requirements

Project Requirements Gathering Best Practices

The primary purpose of requirements gathering is to identify what you need to deliver the scope of the project. When you start from that perspective, you don’t add requirements that are good ideas or niceties. You’re only interested in adding requirements that are necessary to produce the scope. As a result, the process starts with defining the scope and the major deliverables that will lead to that scope from where you are now.  Each of those deliverables, from the scope on down, has its acceptance criteria. It includes the lower-level deliverables that you derived by breaking down the high-level deliverables. The acceptance criteria are metrics that let you and the sponsor objectively measure if you delivered the project scope. An example of an acceptance criterion might be, “Fewer than 3% of the customers are on hold for more than 30 seconds.” That is objectively measurable and everybody will know what they will get from that deliverable. As importantly,  they’ll know what they’re not going to get from the deliverable. They’re not going to get 1% of the customers on hold for more than 30 seconds. They will get 3%. This is not to say that these acceptance criteria can’t change. They can and do change during the life of the project. However, when you define your deliverables in the requirements process with objectively measureable acceptance criteria, you don’t have to argue whether a change request is or is not within the original project scope.

When requirements gathering begins, you will start with that overall project scope and 4 to 7 major deliverables that will get you there. Your next step is requirements interviews. You’ll talk to the individuals accountable for producing those high-level deliverables. You’ll find out what they need to produce the deliverable; what their requirements are for producing each one. Rather than asking the accountable individuals what they want, you’ll ask them what is required to produce that deliverable. You’re not going to add any requirement that is not necessary. This will be a very sharp departure from the Santa Claus technique many people are accustomed to. But when you take this focus, you gain two very significant benefits.

First, by breaking down the project into a hierarchy of deliverables and then identifying what you need to produce each of those deliverables, you are less likely to miss requirements. That is not to say it’s impossible. But this requirements gathering based on the scope and deliverables in the project is very effective in identifying everything you need. You avoid those last minute requirements that spring up out of the weeds near the end of the project. Surprise requirements kill the project duration and budget.project requirements

Second, when you focus on what is necessary to produce the project deliverables, you are less likely to add unnecessary “requirements” to the project.  This will allow you to finish faster and spend less money to deliver the scope the sponsor wants. When you extend this requirements gathering technique to change requests, you make change control easier. When a stakeholder or user comes with something they want to add to the project, you ask why this addition is necessary to produce that stakeholder’s deliverable. This moves the discussion about a change request from a debate over the general value of the addition to a discussion of why it’s necessary to deliver the project scope. That is a more effective basis for discussing additions to the project scope. Project managers almost always lose the discussion about the “value”  of the addition. The issue gets escalated over their heads or they have a very unhappy user. When you ask the user to explain why the addition is necessary for delivering the scope, the discussion is much more focused. If the stakeholder or user can’t make a case for why the addition is necessary, you have a reasonable basis for recommending that the sponsor not add it.

Project Requirements Management

Projects often fail because their project managers and sponsors have ignored the advantages of project requirements management. Some people think it sounds like an invitation to endless paperwork and pointless meetings. However, project requirements management helps you finish the project on time and within budget. That makes your stakeholders happy with the project results and with your work. If you are not doing a good job of project requirements management, you will be fighting a losing battle every week to control scope creep. Your projects will finish late and over budget and your stakeholders will not be happy.

Projects that lack project requirements management drown in scope creep. Despite the “Project Santa” adding lots of “goodies” to the project during planning, the users and stakeholders are unhappy because they spend every week arguing with you about things they feel are required. Those arguments end with the stakeholder going to their boss, who then talks to your boss, who then makes a phone call. The sponsor adds the latest “goodies” to the project without giving you an increase in the schedule or budget.

Good requirements management lets you avoid new requirements springing up every week. Instead of fighting all requirements, you should do everything you can to discover them early, during the initiation phase. Your organization probably has information about earlier projects that suffered the consequences of poor requirements management. It’s helpful to have some real-life project disasters to cite. You want the sponsor to understand that when there’s a lot of pressure to start work quickly,  requirements gathering is cut short. You want your users and stakeholders to understand how you are going to manage requirements on your project. You need the sponsor, users and stakeholders to invest the time to state their requirements on the front end of the project. These people are probably in the habit of putting off their participation in requirements gathering for as long as they can.  That simply ensures you can’t gather all the requirements before you start work. When new requirements arrive late in the project, they cost much more to add than they would have if you had planned for them during initiation.

To manage project requirements correctly, you need to convince the sponsor to allow sufficient time to gather them. Yes, that will mean you start the actual work later. However, when you do start work, everyone will know what is, and what is not, included in the project. That will shorten the overall duration of the project. You need to convince the sponsor that a few days or a week spent gathering requirements on the front-end is worth it because you won’t have the wasted time and money adding requirements every week.

You can learn the techniques for effectively managing your project requirements in our online project management basics course. You’ll work individually with your instructor at your schedule and pace. Take a look at the course in your specialty.

[button link=”http://162.144.114.198/~jwkdwgmy/it-project-basics-111/” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/project-management-basics/” size=”medium” style=”info” color=”#1e14a8″ border=”#940940″ window=”yes”]Business[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/construction-project-basics-121/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Construction[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/healthcare-project-basics-131-2/” style=”info” color=”#1e14a8″ window=”yes” bg_color=”00000000″]Healthcare[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/client-project-management/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]

Get free articles and videos like this every week

Posted on

Project Approval

 Project Approval Process

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

The project approval process varies from organization to organization. In some, it is a rational process of strategic and tactical planning. In others, it is a highly charged political game where project managers keep their backs to the wall to avoid a dagger from behind. Whatever the environment, there are two classic fantasies that executive sponsors play whenever the phrase “project approval” is mentioned. There is also a game project managers play to cope with the sponsors’ demands. Project Phases Main Page

Project Approval is Executive Fantasy Land

Project sponsors and high-level stakeholders think that if their organization has good project managers, the project approval process will go like this:

The project manager strides confidently to the front of the Board Room. The long table before them is filled with corporate big shots. The PM makes one rock solid commitment after another. There is no whining about contingencies or risks. The PM listens politely to a question about budget and the completion date and then says, “We WILL complete the project for $3,123,876.56 and the last of our 1,347 tasks will end on March 9th, 2016 at 3:42 PM.”

As the executives applaud, the PM holds up a hand for silence and says, “That’s Eastern Standard Time,” and flashes a shy smile as the executives go wild with excitement and awe.

Executive sponsors who live in this fantasyland think that projects have no risk. Budgets and completion dates can be set in stone and any failure to hit them means that someone goofed off and didn’t do their duty to the organization.

In this project approval fantasyland, a project is a machine. The executives push buttons and twirl some dials and the project machine spits out the result on time and within budget. Sponsors merely give project managers the budgets and completion dates and they all come true with a little hard work. If an executive wants a project result early, it is just a matter of twisting the “due date dial”.

This project approval fantasy triggers a lot of destructive executive behavior:

  • They force change after change on a project and then feel personally betrayed when it is late or over budget.
  • They treat a project manager as a fool and a liar when the PM won’t give them a finish date commitment during the first planning meeting.
  • They sneer at requests for budget and duration extensions, considering them a sign of weakness and sloth.

Project Approval is a Used Car Lot

In other organizations, the roles and actions surrounding the project approval process resemble transactions on a sleazy used car lot. The executives are the innocent customers and the PM is a slick shyster in fancy clothes. Here the approval process goes like this:

The executives stroll onto the used car lot, looking for simple but effective transportation. No high-powered hot rods, no fancy wheel covers or custom interiors. Just a basic car to carry the executives where they want to go. The PM slithers out from under a rock and wraps an arm around all the executives. “I’ve got just the thing for sports like you,” the PM says in an oily voice.

“We are not ‘sports’,” the executives say. “We just want a basic car; something simple and cheap.”

“That’s what I was saying,” the PM says with a snicker. “Let me show you this beauty. I’ve been saving it for just the right customer.” The PM leads the executives toward a far corner of the lot.

On the way, one of the executives spots a simple economy model and says, “Wait, that’s what we want!”

The PM sneers, “Everyone will laugh at you if you drive that wreck. It’s outdated, antiquated and uses ’80s technology. You’ll be laughing-stocks.”

Scared at making a mistake, they follow the PM to a dark corner of the car lot. The PM pulls an enormous drop cloth off a vehicle, saying, “Here’s what you want!”

The executives peer into the gloom and see an enormous vehicle that will carry too many people. The interior is plush leather, there are 3 stereo systems, 12 speakers, a TV and a wet bar.

The executives protest, “This is too much, too big, too expensive. We want the little car back there!”

The PM starts to talk, waving complex charts and graphs and saying, “This is the latest technology, the best economy and the. . .”

The PM’s pitch mesmerizes and hypnotizes the executives. A few minutes later, they drive off in the big expensive monster.

This project approval approach also triggers a lot of destructive executive behavior:

  • Sponsors review project plans with a fine-toothed comb, searching for unwanted and unneeded features, options and fixtures.
  • They think every number a project manager presents is a lie. Cutting their duration and cost estimates is just getting rid of all the padding.
  • Project managers hide tasks in their projects to give their friends an easy time at work. They believe 33% of all the project tasks fall into this category and they can eliminate them with no consequences.

Project Approval by a Rookie PM: The Eager Puppy Dog

Too many PMs play the eager puppy dog in project approval presentations to stay out of trouble. The approval discussion goes like this:

The sponsor says, “I think this budget looks just a tad fat. You can get it done for 20% less, can’t you?”

The PM nods like an eager puppy and hurries off to slash the budget by 20%. The easiest way to do that is to reduce the work and time in each task by 20%. The PM is able to return with the lower budget and, as a bonus, a shorter duration. This convinces the sponsor that the PM is not a slick shyster and that the project will run like a machine.

When the project approval session ends, both the sponsor and the PM have learned a lesson. The sponsor has learned that the PM’s plans have a lot of fat built in. So next time the cut will be 30%, not just 20%. The lesson the PM has learned is that next time he’ll pad the plan by 25%. Then arbitrary changes won’t cripple the effort before it even starts.

Project Approval by a Rebel Without a Clue

Still other project managers prepare to go into project approval meetings ready for battle. Holding a clenched fist into the air, these rebel PMs tell the team members, “I will fight for our plan! Those nitwits in suits will not change one bit of the brilliant plan we have put together.”

The rebel then heads for the meeting room for the planning session with his boss, his boss’s boss and the executive whose signature is on his paycheck. The discussion goes like this:

The executive asks, “What will it take to finish a month earlier? We have two other competitive initiatives and I would like all three to hit the market at the same time.”

The PM says, “Finishing earlier is impossible! There is no way we can finish any earlier than June 30th. Even that date will require so much overtime that the team members’ family lives will be horribly disrupted. There’s no way. We can’t do it!”

The controller says, “I’d like to see a little less use of consultants and lower fees. Don’t we have internal people who could do some of this work? Maybe they can work with the consultants.”

The rebel PM answers, “Impossible, we need their expertise and I have negotiated their fees down to a fraction of what they charge other companies.”

These executives huddle for moment as the PM waits behind the podium.

Then the most senior executive says, “We approve the project with a completion date of April 30th and a budget that is $25,000 less than your plan. We’re also more than willing to find another PM if you can’t hit those targets.”

The rebel explains the executives’ treachery to the team members and no one learns any project approval lessons.

Summary

The key to successful project approval meetings is for PMs to be ready with options and alternatives for finishing earlier, spending less money and using alternative resources. Good project managers are eager to change the plan to fit the executives’ requirements if the scope, budget and duration are feasible. Learn how to use our proven project approval process and create trade-offs between scope, budget and duration in our online courses with your personal instructor. We can also design a customized seminar for your organization and deliver it online or at your site.

Posted on

Collecting Requirements

One of the key phases on every project is correctly collecting requirements from the user. In the past 10 years I have never seen a project of relevant size that didn’t have changes requested, either during build/execution phase or during testing. Requirements Main Page

Waterfall Approach

A rigorous waterfall project approach that firstly requires collecting Analogous Estimatingrequirements documentation to extreme details by users, and after analyzed by architects, designers etc., caused three negative side effects: First, the requirements collection phase has been lengthy, it consumed a big amount of resources, and time after time near the end, users tended to short-cut in order to respect the deadlines. Second, the users become too attached with their requirements, in some cases, unwilling to compromise even for the sake of respecting scope, time and budget. And last, the users were biased to go to much in details, mainly driven by the concern that this was their only chance, they might forget something and later be taken responsible.

The result was over-engineered projects, which after consuming all the budget and time, still had additional requirements and changes coming in later. In the worst case the project end phase became some sort of drama and blaming game. Main Requirements Page

To address this situation, the key was to find a balance with the users. To aim somewhere between no-details, to-vague, to-much and over-detailed. We successfully tried some simple steps to improve the overall project performance.

First, we started by demystifying the process and removing the mistrust from the involved users. We told everyone changes are part of life, they are not to be feared, instead they are to be managed.

Second, we switched from an approach of pure waterfall where we were expecting users to deliver a full list of requirements to the architects and designers, to an approach where users and the experts sit together in a “war room” and discuss and enrich each requirement.

Third we invested a lot in communication with the users to agree to leave apart requirements they were not sure of. Better leave something you are not sure out, then to add something you do not need in the project. This was done by explaining with details the costs of complexity, as a maintenance cost you bear for all of the system’s life. This cost in the end affects the end users.

Forth, we planned in the project a second revision phase, to address changes and overall improvements. It was planned as a ball park, and to be elaborated later, as PMI calls it rolling wave planning.

To date, after 4 years of using this technique, significant improvements in the project performance were achieved.  In the past we had to work from time to time on ridiculously complex requirements that would have been used in rare circumstances, and yet the users insisted in having them, fearing they would lose their chance if it was left out. This new approach resulted in simpler solutions, a faster delivery to market, fewer rows of code written, meaning less defects.

In some aspects our experience may sound as it deviates from PMI best practices for thorough planning, yet it is related to rolling waive planning and in our experience has proven to deliver excellent results. More on Requirements

Posted on

Prototyping in Project Management

Prototyping in project management can be effective in many situations is very attractive to users.  Phototyping consists of planning and then developing a sample deliverable for the users to review and modify.  Prototyping reduces the pressure on users to specify all of their requirements before works starts.  So we would talk to the user and make a plan then produce it. The user would review with make changes and then we would produce another prototype for the user to review and modify.  Producing one prototype after another allows us to iteratively, prototype by prototype, developed the deliverable.  Depending on the deliverable, prototyping can be very expensive and time consuming. But is a user or client wants you pay for this approach, a good project manager can accomodate them.

The classic waterfall approach where we finalize the whole plan IN a lengthy planning effort, and then execute the plan,  is cheaper.  It does however require 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 exams iterations.

Prototyping Communications is the key

The issue with Project Requirements Prototyping is a communication. We humans express our thoughts and needs using a biased, misunderstand able medium, the spoken language. The information is warped using our biology, emotions, past experiences, culture. This message is transmitted using our communication skills (often limited), and is in its turn unwrapped by other humans that add in the mix their own experience, biology, emotions, experiences, culture. The result, as you all might have experienced, is very often distorted. People discussing the same topic, walking away with different pictures in their mind. During the collection of project requirements, this risk, inherent from the deficiencies of our spoken language is considerable. In my experience, the communication gaps have been the key reasons for failure. For the same reason mathematicians, physicist has used formal language for hundreds of years.
Few years back, acknowledging how problematic are the misunderstandings in requirements we decided to invest some resources in preparing a prototype, before starting the work. The team of business analysts would be responsible to prepare it.

Example Requirements Prototyping: Business Analysts

It would work like this; the BA would start with something simple as soon as they could, without waiting for the full set of the requirements to be prepared. The prototype would then be showed to the business users and technical teams. The comments from both sides would be incorporated to the prototype and then showed back for discussion. We went for up to 10 iteration until a stable and final version emerged. The target was to keep it simple, meaning the prototype did not have to be fancy or based on some complex platform. It was enough if they just sketch it on paper and then sit with the users and the technical team to shape it until reaching a satisfactory state for all the parties. In the end, the prototype would be signed upon as the final agreement between all stakeholders.

The first project we applied this concept was the automation of teller system for a bank. The result was very bad, and good at the same time. The analysis phase finished more than a month in late, as the prototype seemed to be changing repeatedly. On the positive side if these changes were coming in the testing phase, it would create a huge mess. On the user’s side, they loved it, as they had the certainty important parts were not left out, and could immediately picture the product. It gave the possibility to visualize the requirements allowing all the involved stakeholders to reach an agreement, narrowing the gap between the need and the technical capabilities. As well, it helped the business users to more critically assess their thoughts and as it resulted, often adapt part of requirements.

Of course, it’s not always easy to choose and prepare the right prototype. In data processing systems like data warehouse the prototype could be an excel worksheet with the input data and the transformation formulas. For interactive, user based systems it was more about GUI design, validation rules etc. Through the years, the process has been refined, and users got more capable at it. We currently do use tools that are more advanced, still the concept is the same simple one and every time we find the complexity of a tool limiting, we go back to drawing on whiteboard.