Steps to Gather Requirements

Knowing how to gather requirements is a skill that every analyst, and project manager, – should have. However, it seems to be a skill that is generally lacking in many organizations. Poor requirements gathering is a major cause of project problems in many organizations. 

Gathering requirements is more than just asking a few questions and then proceeding to the next step in the lifecycle. We have a four-step process for gathering requirements that all projects should utilize to some degree. If your project is small, you will go through thee steps quickly. Larger projects may spend quite a lot of time working through the process.

  • Elicitation. The Elicitation step is where the requirements are first gathered. To elicit accurate requirements, the analyst must ask the right kind of questions and then listen carefully to the answers. There are a number of techniques for eliciting requirements and your project may need to use multiple techniques depending on the circumstances. This includes interviews, facilitated sessions, prototypes, questionnaires and more. 

  • Validation. The Validation step is where the “analyzing” starts. The purpose of validation is to make certain that the information conveyed during elicitation accurately represents the needs and expectations of the clients and stakeholders. The work here includes consolidating requirements, rationalizing them, looking at overlaps and gaps and creating models to help visualize processes.

  • Specification. During this step, the analyst prioritizes and formally documents the requirements in a Requirements Definition Report. The requirements are also numbered in a way that allows them to be tracked through the rest of the lifecycle. Finally, they are checked to make sure that they can ultimately be tested.
  • Verification. The final step in the requirements gathering process is verifying that the documented requirements accurately and completely communicate the needs and expectations of the client. The requirements are reviewed and formally approved. During this step, the analyst can also develop acceptance criteria and start to write test cases for the final solution.

The truth is that all team members need to appreciate the value of good business requirements and should have some fundamental skills in gathering them. Gathering good requirements up-front saves time and money and improves the overall quality of your product.

Are Two Programmers Better than One?

One of the most interesting aspects of Agile methodologies is the technique of pair programming. This is specifically described in the Extreme Programming (XP) model.

When I mention pair programming for the first time I am usually met something like “Dude you can’t be serious.”. On the surface, this seems counterintuitive. After all, isn’t programming the bastion of the lone wolf? The typical programmer receives design specs and then sits down at the terminal to code, code and code. It does not seem to make sense that one programmer would code and another would look over her shoulder.

Even though it may not be intuitive, the technique has been shown to work. In fact if it did not work, it would not be considered a staple of Agile development. Pair programming has a number of advantages.

  • The code is of higher quality. One programmer writes code and the other programmer watches and provides immediate feedback on the overall design and accuracy of the code. Logic errors tend to be caught quickly since the thinking of one programmer is immediately validated by the second.

  • More code can be written. Programming in pairs results in more code than if only one person is involved. This is because each person takes turn writing code. In fact, between the two programmers the coding can continue almost non-stop over the work.

  • The code is cleaner. A lot of faulty code gets written when a person is fatigued. Pair programming keeps the pair fresh by alternating the roles of the coder and the reviewer. This results in fewer programming defects.
  • Requirements can be validated sooner. If one programmer misinterprets a user story, the second programmer can catch the error immediately.
  • Code reviews are not needed. Code reviews are a time when the code from one programmer is reviewed by peers. The need for code reviews is generally eliminated since the code is validated by a peer at the same time it is written.

“Programming” includes the initial code development, testing, and the time for defect correction and rework required to ensure the code is complete and correct. Teams that use pair programming have found that the technique actually results in increasing programming productivity by twofold or more. In other words more then twice as much clean code gets implemented with pair programming as compared with two programmers working independently on different programs.

Ways to Turn Around a Dysfunctional Team

Many teams have some personality conflicts among team members. This is a typical human resource problem. However, on some teams the personal animosity is so great that the team has a hard time functioning together. When this problem is recognized by the sponsor or the functional manager, the project manager is often replaced (this is usually an easier option than trying to replace the entire project team).

If you are a project manager that takes over a dysfunctional project team, there are a number of areas that require your attention.

The first thing you want to do is assess the current state of the project. Your response to the project team problems will depend on where you are at with the schedule. For instance, if you have 30 days of work remaining, you will have less ability to make an impact on the team dynamics. In this case, the best course of action may be to try to motivate the team for the final push and watch the schedule closely. On the other hand, if your project has many months to go, then you need to see what can be done to repair the damage on the team as well as re-plan the schedule to deliver on a new realistic time frame. Any plan is going to include the following items: 

  • Communicate well. If the project manager is a poor communicator, it can result in a miserable project experience for everyone. Teams with poor morale tend to have poor communication channels. Don’t let rumours and uncertainty fester. Make sure you share as much information as you can about the project status and anything else that may impact the project team.
  • Praise and compliment. When people on your team do a good job, make sure they know it. People don’t expect money or gifts when they do a good job – just a pat on the back and a ‘well done’ by their manager. Give it to them – both informally and formally.
  • Set clear expectations. People need to understand what is expected of them so that they know the challenges they need to meet. Make sure you give clear instructions when you hand out work so that people understand what they are expected to do.

  • Don’t over commit your team. As you try to improve morale, you also need to be careful not to over commit the team. Determine the work remaining to finish the project and remove anything that is extraneous or can be done after implementation.

  • Win some small battles. Poor morale can cause your team to miss deadlines, which causes more pressure and degrades morale even further. The opposite is true as well. If the team can start hitting some interim deadlines (and you communicate this fact and praise them), the team morale should improve, which may make it easier to hit your next deadline.

These are some ideas for turning the project around. Make sure you try to identify as many team problems as you can, as well as the root causes if possible. Then, put together an action plan based on how much work and time is remaining on the project. If there is not a lot of time remaining, focus on the schedule. If a lot of time is remaining, focus on repairing the project team, as well as completing the schedule.

Using Agile on Large Teams

When the Agile movement gained steam in the early 2000’s the conventional wisdom was that Agile worked well on smaller projects but did not scale well for larger ones. This seemed to make sense because as projects get larger and team size increases, the team needs more coordination, more structure, more documentation, etc.

It is true that running a 50-person Agile project will not work if you use the same processes that you use for a 10-person project. But this is true for conventional  projects as well. As projects get larger, it is important to change your approach to be able to deal with the complexities. For an Agile project, the first and primary technique is to break the large project into a number of smaller Agile teams. For example, a 50-person Agile project team may be too complex to manage. (Any 50-person team would be complex to manage.) But what if the 50-person Agile team can be reorganized into five 10-person Agile teams (or four 12-person teams)? Each of these teams can be run more effectively using Agile techniques. Each Agile team is not split by role (analysts, designers, coders). Each team has a full staff and is able to work as a “normal” Agile team.

Of course, if you break a larger team into smaller teams, you have to coordinate the work and manage the interfaces and hand-offs. In a traditional project, this would be the job of the project manager and perhaps team leaders on each sub-team. On an Agile project, each team assigns an individual to be responsible for coordinating work with the other teams. This person is sometimes referred to as an “ambassador” since they represent an entire Agile team to the other Agile teams. The ambassador role can be rotated among the Agile team members.

Communication on the large Agile team takes place at two levels. First, each Agile team continues to meet in a daily standup status meeting. This is referred to as a daily scrum. The ambassadors for each team also meet daily. This meeting is sometimes referred to as a “scrum of scrums”. This communication at the team and the project level ensures that each team can work independently while still creating an integrated solution.
Other specialists on each team can communicate as needed.  

Ways to Lead Your Team on Late Change Requests

Project changes usually result from two causes. First, the stakeholders do not understand all of the details and nuances of what they need at the time you ask them. The second reason for project change is that the business is changing, the industry is changing and the world is changing. The needs of your project may change as well.

Usually scope changes are not much of a problem. However, changes can be more disruptive and problematic if they come in late to the project. If your project is already long and the proposed changes require a lot of work, the team may resist adding additional work. This can be a common problem because late changes usually require quite a bit of work to retrofit back into the solution.

Having to complete late scope change requests can be a problem for the project manager. The team is tired and they are not motivated. In fact, morale may be poor. However, this is the time for the project manager to show leadership. Here are some things for the project manager to consider.

Explain the facts first. Do not start with a rah-rah speech right away. First, meet with the team and explain the background and circumstances. Then, talk through the changes that are needed and why they are important from a business perspective.

Acknowledge the pain. The project manager must acknowledge the problems. Let the team know that you understand that they may not want to make the changes and that their morale is poor. Don’t dwell on it – but acknowledge it.

Be motivational. Okay, now is the time to motivate the team. Appeal to their sense of working together as a team to get through this adversity. Let them know the value they are providing to the company.

Talk to everyone one-on-one. In addition to the team meeting, talk to the entire team one-on-one to understand where they are at mentally. Listen to their concerns and get their personal commitment to work hard and keep going.

Get management and the sponsor involved. Now is also a good time to ask your manager and your sponsor to talk to the team, thank them for their work so far and ask for their continued help getting through the changes.

Look for perks. Little perks can help a team get through motivational and morale trouble. These can be as simple as donuts in the morning and pizza for those that have to work late overtime.

Make sure the clients are in there with you. Normally if the project team is working extra, the clients are sharing the pain as well. However, the project manager should make sure they are.

Communicate proactively. Keep everyone informed as to the state of the project and the time and effort remaining. If the project manager starts getting closed and secretive with information, it causes many more problems to morale.

Celebrate successes. The project manager does not need to wait until the project is over to declare success. Look for milestones, or mini-milestones, as opportunities to celebrate a victory and give praise to team members.


A project manager needs to have more management and leadership tools than simply telling people to “do their jobs.’ Implementing late change requests requires good people management skills to get through successfully. Success is never guaranteed, but utilizing some of these tips can help you get though a tough situation.

Options When Managing Projects With Unrealistic Deadlines

If you are a project manager dealing with what you perceive to be an unrealistic deadline, the first thing you will want to do is talk to your sponsor to see if there are any business factors that are driving the deadline. For example, there may be some event occurring that this project needs to support. On the other hand, sometimes managers set arbitrary end-dates just to provide what they consider to be stretch objectives. You may find that by better understanding the reason for the deadline, you may have an easier time getting the team motivated to achieve it.

Once you understand the cause for the deadline date, there are project management techniques that can be utilized to increase the chances of success.

  1. Increase resources. If you find that the deadline is not in alignment with your resources, talk to your manager about increasing the resources that are available for the project. Adding resources to the project may increase the cost, but may allow you to hit the deadline. If the deadline is most important this may be a viable option. 

  2. Reduce scope. Talk to your sponsor about reducing the project scope. See if there are features and functionality that he can live without for now so that you can deliver the project within the deadline specified.

  3. Identify and manage the deadline as a project risk. Utilizing risk management will help better manage expectations early in the project and also be a way to gather input and ideas for ways that you might be able to hit the deadline.

  4. Manage scope with zero tolerance. On many projects, you start with an aggressive delivery date, and then the situation gets worse because you do not effectively manage scope. It is absolutely critical that you manage scope effectively and do not increase scope without an appropriate increase in budget and timeline.

  5. Manage the schedule aggressively. In many projects, you might get a little behind but have confidence that you can make up the time later. However, when you start a project with the deadline at risk, be sure to manage the schedule diligently. You have no margin for error. As you monitor the schedule, treat missed deadlines as problems and work hard to solve the reasons behind the slippage.
  6. Look for process improvement opportunities. Lastly, take a hard look at your schedule and your approach for executing the project. Talk to your team, clients, and manager about any ideas they may have for making the project go faster. This will get everyone thinking about being part of a solution. 

Although it appears that you are being held accountable for events and circumstances that are not within your control, you do have control over the processes you use to manage the project. Use them proactively and wisely.

Refactoring Agile Code

In a traditional development project there is a tendency for one person to write entire programs to implement certain functionality. It is likely that once a program or component has been written and tested, it will never have to be updated again during the project. This is not the case with an Agile project. Agile projects build incremental solutions over time. It is very possible, and perhaps likely, that a component that was written to support a specific piece of functionality may need to be updated later with the introduction of some other use case with related functionality.

On an Agile project when the second Developer works on a module that another Developer worked on previously, a couple things need to happen. First, the second Developer needs to review and understand the work of the prior Developer. Second, the second developer needs to insert new and revised code to support the new functionality.
When the second Developer reviews the code, it is possible that he may have some ideas to make the code more efficient or easier to support. In a traditional project, there is a tendency to leave this inefficient code in place. The thought is that “if the code is not broken don’t fix it.” This is considered a more cost effective approach. Therefore, prior code that seems to be working tends to be isolated so that new changes do not impact it. This approach usually results in code that becomes very “brittle” over time. “Brittle” means that the code tends to break or that errors are introduced whenever this old code is touched.

Agile projects take the opposite view. If a subsequent Developer has concerns about the way a component is coded, or if he thinks the code is not as efficient as it needs to be, the second Developer takes the time to update the code. This constant review and modification of code is called “refactoring.”

Refactoring is the expected practice of continually updating prior code if the current Developer thinks that the code can be improved, better documented, or optimized.
Refactoring may or may not take a little more time to write and test during the current iteration. The greatest danger of touching old code is that you will break something that works today. However, this risk is minimized on Agile projects by automated and rigorous testing so that any new errors can be quickly discovered and fixed. Any short-term impact is offset by continually delivering better and better code over the life of the project. The code will be cleaner, more efficient, more flexible, better documented and much easier to support longer term.


Refactoring is one of the philosophies that are unique to Agile. It is not just something you do if you see a major problem. It is a mindset that you have whenever you make changes to an existing component. When traditional project teams may shy away from the practice, Agile teams embrace it. The result is the ability of Agile teams to maintain more flexible and efficient solutions all the way through the Agile project.

Reasons to re-Authorize Projects

When projects get approved they should be placed on a pipeline until the organization has the capacity to staff the project. It might seem that once a project makes it through the approval process there is a commitment to start. This is not the case. There is one more step that has to happen before a project can actually start – authorization.

The authorization process is the point where the budget is actually allocated to the project and the work is ready to begin. All of the approved projects cannot start at the same tome. There are a number of reasons why the project may not start for a long time after the project is initially approved. The Authorize step to make sure that the project is still viable. There are a number of things that need to be validated before the project begins.

  • Validate the Business Case. The time lag between approval and when the project is ready to start may have changed the Business Case. For instance, it is possible that a competitive opportunity has come and gone.

  • Validate sponsorship. It is possible that the client is no longer committed to the project. This could happen with changing priorities and it could also happen with a changing of the sponsor.

  • Validate staff. You should not start a project without staff availability. It is possible that the resources that were going to work on the project are no longer available.

  • Validate budget. It is possible that budget cuts, or overruns from other projects, have resulted in a lack of funding for the project.

  • Validate detailed estimates. Once the project manager is assigned, the project planning process begins. This will result in an estimate of effort, schedule and cost at a greater level of accuracy than when the Business Case was created. It is possible that the more accurate estimates prepared at this time will result in the project no longer being viable.

  • Validate priorities. It may be that nothing has changed on a project that was approved. However, business changes during the year may have resulted in a number of new projects with high priorities. These new projects may take the funding that was originally allocated to another project.

You can now see that there are a lot of reasons why a previously approved project may no longer make sense by the time it is ready to be staffed. It is usually the case that the shorter the timeline between approval and authorization, the more likely it is that the project will in fact proceed as envisioned. Likewise, the longer the lag between the project approval and readiness to begin, the more likely it is that the project will no longer make sense. If the project no longer makes sense, then it should not be authorized.

Use Pareto Analysis to Solve the Most Important Problems

Pareto analysis can be used when you encounter multiple related problems or a common problem with multiple causes. The purpose of Pareto Analysis is to observe the problems and determine their frequency of occurrence. This, in turn, gives you the information you need to prioritize your effort to ensure you are spending your time where it will have the most positive impact.

Pareto Analysis is based on the classic 80/20 rule. That is, in many cases 20% of the problems cause 80% of the occurrences. For example, let’s say you have a problem with a product failure, based on a number of causes. Through observation and collecting metrics, you determine there are eight causes. Rather than attacking the causes randomly, a Pareto Analysis might show that 80% of the problems are caused by the top three causes. This gives you information to know which causes to solve first.

The tool associated with this problem solving technique is the Pareto Diagram. It is a chart, graph or histogram showing each problem and the frequency of occurrence. It is created as follows:


Developing a Pareto Diagram

1 Project Manager, Team Members

Create a table listing all observed problems or causes.

For each problem, identify the number of occurrences over a fixed period of time.

Problem Count
Problem 1 115
Problem 2 25
Problem 3 5
Problem 4 50
Problem 5 5
Problem 6 15
2 Project Manager, Team Members Arrange the problems from highest to lowest, based on the number of occurrences.
3 Project Manager, Team Members

Create a new column for the cumulative total.


Count Cumul % Total

Problem 1

115 53%

Problem 4

50 77%

Problem 2

25 88%

Problem 6

15 95%
Problem 3 5 98%
Problem 5 5 100%

You could add other columns such as the severity of the problems and the cost and effort to resolve the problem.

Notice that this gives you important information. Even though there are six total problems identified, you need to resolve problems #1 and #3 first (all things being equal). That is where you will achieve the most impact. If you decided to work on problems #4 and #5 instead, the result of your effort would be almost meaningless. This does not mean that you do not want to resolve the other problems. However, this Pareto Analysis gives you information to know the order in which the problems should be resolved. It also provides a sense as to the relative value you receive for resolving each problem. Of course, you may determine that problem #6 can be resolved quickly and you may choose to solve that one early. The Pareto Diagram does not tell you what to do. It provides information to you so that you can make the best decisions.

Reasons Companies Struggle Implementing Project Management

There are many companies that do not have common project management processes, , approach and skills. One initial observation is that companies that don’t manage projects well are usually run by senior managers who never learned formal project management themselves. It is hard for them to lead culture change around project management when they don’t understand the value themselves. In fact, sometimes these managers think of project management as a tool for managing projects, rather than as a process for doing the work. When they discover a tool isn’t involved, they lose interest.

There are a number of other reasons why companies have not implemented project management processes. These include:

  • The company does not have committed sponsorship.

Some managers want to hold a training class and hope that project management sticks. They don’t have a strong commitment to the culture change required to get better at managing projects. In large companies, it could take two to three years, or longer. The sponsor needs to be committed and focused long term to make the changes successfully. 

  • The entire organization is not included.

It’s hard to be a good project manager in an organization that doesn’t value project management skills. For instance, if you take the time to create a Charter document, and your sponsor asks why you were wasting your time, you are probably not going to be very excited about the planning process on your next project. To be effective, the entire organization must be part of the project management initiative.

  • The organization does not have a lot of pain around projects.

This is very common, especially in small to medium sized organizations. In many companies, the projects are not under pressure to complete within fixed deadlines and budgets. They just need to be completed within a “reasonable” timeframe. In these companies, there is not much internal pressure to change the status quo.

  • The organization is not scaling the processes and approach.

A common criticism of methodology is that it is cumbersome, paper intensive and takes too much focus away from the work at hand.  Sometimes this is a legitimate concern, caused by not scaling the methodology to the size of your project. For instance, if you were required to develop a fifteen page Project Charter even if your project is only 200 hours, you may have been turned off. This is not usually a methodology problem as much as it is a misapplication of the methodology.

  • The project teams fight the changes.

Many people want to solve problems and do their jobs creatively, with a minimum of supervision. They fear that project management techniques will result in controls that will take the fun out of the work. Without strong sponsorship, the project teams resist the change until the pressure goes away.

  • There is a fear of the loss of control from management.

If you really want to effectively implement a project management discipline at your company, you must give a level of control and authority to the project manager. Some organizations, and middle managers especially, do not want to lose that control. They may want people to coordinate the projects, but then they want to make all the decisions and exercise all the control. Formal project management will not be possible in organizations where this fear is prevalent.


These are some common reasons why project management is not sponsored at
companies, and when it is sponsored, why it does not always stick. However, almost
every study that looks at project management shows that it is a discipline that will help
project managers deliver on time, on budget and within client expectations. All
companies should have a common project management process to maximize the chances for delivering their projects successfully.