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.

Goals, Strategies and Objectives

The definition of goals, strategies and objectives can vary from company to company.

Business Goals

Goals are set at the organization level – not the project level. Objectives are at the  

Goals are high-level statements that describe what are organization is trying to focus on for the next three to five years. They are vague (on purpose) and they are direction-setting. Because the goal is at a high-level, it will take many projects over a long period of time to achieve the goal. The goal should reference the business benefit in terms of cost, speed and/or quality.

Goals are vague, but not too vague. If you can measure the achievement of your goal in one year (i.e. 25% revenue increase by the end of the year), it is written at too low a level and is more of an objective. If your goal is not achievable through any combination of projects, it is probably written at too high a level (i.e. lead the industry). Perhaps it is more of a vision.

Business Strategies

Business goals tell you what is important. Strategies tell you how you are going to achieve the goals. There may be many ways to achieve your business goals. Your organization’s strategies are a high-level set of directives that articulate how the organization will achieve the goals, and ultimately move toward its long-term vision. Strategies are more inwardly focused and usually try to leverage internal capabilities.

Projects may be authorized that contribute directly to the business goals, or the project may contribute to a strategy. For example, many organizations want to get better at project management. Getting better at project management will not directly align to a “better, faster, cheaper” goal. It is more of a “how” so it better aligns to strategy. Your organization could have a strategy to execute projects more effectively and a project management initiative can align to this strategy. 

Project Objectives

Objectives are concrete statements that describe the things the project is trying to achieve. An objective should be written at level that it can be evaluated at the conclusion of a project to see whether it was achieved. A well-worded objective can be Specific, Measurable, Attainable, Realistic and Time-bound (SMART). SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.

Objectives are important because they show an agreement between the project manager and the project sponsor on the main purpose of the project. The objectives should be written in a way that they are understandable by all of the project stakeholders. Objectives are also valuable since they provide alignment to organization goals and strategies. Your organization should not authorize projects that do not tie to goals or strategies

Value-Add PMO

Although PMOs can get into many different activities and processes, the primary purpose is usually centered around projects and project management. This includes project management processes but much more. Many (but not all) PMOs get a negative perception. I think the reason for the negative perception of PMOs is twofold.

  1. First, in many cases the PMO is, in fact, not providing services that result in better project outcomes. They are seen as not providing value.

  2. The second problem is that many PMOs are doing great things, but they are not communicating the value that they provide very effectively.

In some organizations the PMO thinks its job is to write and implement as many standard project management processes, checkpoints and templates as possible. They lose sight of whether the processes are helping or hurting projects and the organization in general. If the processes provide value to managing projects better, that could be good. If the processes result in projects taking longer, that is bad.

We have two main areas of advice for PMOs. First, a PMO should never sit in isolation and ask “what should the PMO do?”. The PMO can do many things or nothing. The work and focus of the PMO can only be answered in context of the organization it is supporting. The PMO should always be evaluating the project environment and asking how it can best support the organization. If the PMO can maintain that alignment it should always be able to demonstrate the value it provides. We refer to this approach as the “Value-add” PMO since all of the work of the PMO is aligned to helping the organization reach its desired future state. The actual work for the PMO is work associated with closing gaps between the current state and the desired future state.

The second way to make sure that the PMO provides value is to adopt a philosophy of “simplicity”. In other words, if you have a choice between a simple and complex process, choose the simple process. In fact, it is harder to create a good simple process than it is to create a large bureaucratic one. That is why most PMOs end up making large processes. They are easier. The key for a PMO is to ensure project managers adopt best practices for rigor and structure, using as simple processes as possible.


The PMOs that provide the most value are the ones that align their work to moving the organization to the desired future state, and that build supporting processes and tools in a sound, yet simplistic, manner.

Diverse Team to Gain Broader Perspective

Hiring the best candidates is one on the most important aspects of the Human Resource organization. Hiring a “diverse” team simply means we have a group of people with different backgrounds, experiences and personalities. Organizations try to hire a diverse workforce, which in turn results in diverse project teams. There are really two arguments for the business case for diversity.  The first is basic fairness and the second is the long-term business value associated with a diverse workforce.

Let’s start with the matter of basic fairness.  A company’s hiring objective is to always find the best person to fill an opening. But what does it mean to be the “best” candidate? Left to their own devices, a hiring manager tends to rate a person’s qualifications using her own background as a measuring stick.  After all, if a manager has a certain background and ended up in the position he is in today, doesn’t it make sense to look for those same traits in another person? This can tend to result in candidates with a similar look and background to themselves.

Companies, especially large ones, have tried to get away from this natural bias by standardizing the recruiting and hiring process in a way that allows each candidate to be judged based on the same set of criteria. The goal of the standard process is simply to ensure the most qualified candidate is hired. 

Diversity also provides real business value to the company. Society as a whole is diverse and all companies exist and sell products in this diverse marketplace. Companies have discovered that a diverse workforce translates into being able to prosper in a diverse marketplace for a couple reasons.

  • Exploiting the marketplace.  It is hard, if not impossible, to effectively reach a diverse marketplace without a diverse staff. You need people with diverse backgrounds to be able to thrive in a diverse marketplace. 

  • Making better decisions.  People from the same types of backgrounds can have a tendency to think alike and this can affect the decisions that people make.  Managers need a diverse set of opinions to make the best goals, objectives and strategies for the company.  Of course, some people are very creative, but it is hard to be creative in areas where you have no background or context.  Having a diverse management structure helps drive better company decisions in a diverse world. 

Acquiring the project team is one of the responsibilities of a project manager. Sometimes this leads to hiring decisions. This discussion on diversity will help you understand why most companies feel that hiring a diverse workforce is important.

It is worth stating again that a focus on diversity does not mean that you hire inferior candidates. It is really focused on removing any conscious or unconscious biases so that the best candidate can, in fact, be hired



Administrative Skills Every IT Manager Should Have

Technical knowledge is only part of the IT manager skill set. It’s also essential to be able to support the team, anticipate and resolve problems, and run interference when political issues arise.                     

IT pros tend to bristle at the idea of administrative skills, which many perceive as sitting in an office instead of doing work that really needs to be done. Nevertheless, administrative skills play a major role in getting IT work done. These skills are indispensable for IT managers, who constantly walk a line between enabling their staffs to do work and clearing political issues with business users so work can proceed.

Here are 10 administrative actions every IT manager should be able to handle.

1: Fighting the good fight for the budget

If worthy projects that require business value aren’t sold to management, work stops. Staff depends on IT management to sell their work, so it is virtually impossible to “over prepare” project justifications, returns on investments — and of course, the numbers to convince others why IT projects should proceed.

2: Acting quickly when problem situations emerge

Whether they are political, technical, strategic, or operational, problems can quickly surface from nowhere. When this happens, go after them before they turn into full-blown situations, and always strive for clean resolutions so they don’t come up again in another situation.

3: Praising employees

Most important factor is recognition.

4: Building teamwork

Everybody preaches teamwork. But if your company has a culture that is fiercely competitive — with everyone feeling that they have to constantly promote themselves to be recognized — teamwork will be impossible to achieve. It’s amazing how many managers still don’t get this.

Managers who are strong administrators understand the complexity of day-to-day IT. They know that IT can’t effectively approach projects without a solid and committed team. Accordingly, they “walk their talks.” They are the first ones to do whatever is needed to assist the efforts of others, and they let others see this in the form of exemplary behavior.

5: Demanding accountability

In a team environment, individuals must accept responsibility for their work or everybody loses. There are always some individuals who refuse to accept responsibility when things go wrong or who try to pass it off on others. It’s the manager’s job to be familiar enough with the situation to be able to see exactly where things went wrong and who was accountable for it. This breaks up attempts at trying to pass the blame to others, which can demoralize the team. It is also the manager’s job to let the staff know that everyone makes mistakes. The key is owning up to your responsibilities and taking corrective action when you need to.

6: Being accountable yourself

This is a given, if you’re going to demand accountability from your staff. You won’t get it unless you practice it.

7: Deflecting politics away from the team

In technical disciplines like IT, there is always an abundance of strong technical performers. But the flip side is that most IT’ers have an inherent aversion for politics and would just as soon occupy themselves in the “world of things.” This is why one of the biggest favors managers can do for their staff is to take on the political battles and pressures. If they can clear the way politically for work and projects, those things usually take care of themselves.

8: Building good working relationships with upper management

The politics of business and IT go smoother when there are solid trust relationships between upper- and middle-level managers throughout the company. Managers with strong administrative skills intuitively know this. They work hard at relationship building with their peers throughout the organization, and do everything they can to build trust in the work that IT undertakes for the business.

9: Looking for burnout

IT professionals are highly driven. The best won’t quit until they’ve finished a major piece of work or solved an elusive problem. That’s exactly what a manager wants: the knowledge that if a problem is there and it’s three a.m., that there’s a dependable person working on it. But there are also IT pros who will put themselves in these “do or die” situations day after day. You want this commitment — but everyone needs to step away periodically so they don’t burn out. The highly driven individuals who thrive on the pressure will never tell you that they need R&R. That’s why great administrative managers regularly tour the trenches, looking for signs of burnout. When they see it, they step in, often rewarding the person with a comp day off.

10: Clearly defining projects, work, and goals

Even with lean budgets, IT staffers are resourceful and creative. They will usually find ways to get any type of project done. However, they can’t do this if they don’t understand the objectives and the outcomes of the work. Good IT managers never authorize a project that doesn’t have clear requirements, goals, and expected outcomes. They authorize project prototyping and sandbox work only if there is an objective, as well as a point where work gets cut off before it becomes unproductive. This is the degree of definition that an IT staff needs to be productive. It is the responsibility of the IT manager to see that it is there.