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.

Strategies for Responding to Risks

Identifying risks is only the start of the risk management process. If you identify a risk you are obligated to create a risk plan to respond to the risk. You should create a risk response for all “high” risks. There are a number of general options that the project manager should consider for responses.

  • Leave it. In this approach, the project manager looks at a high risk and decides to do nothing. This can happen for one of two reasons.
    • First, the project manager may feel that cost and effort of managing the risk is more than the impact of the risk event itself. In this case you would rather deal with the costs of the risk occurring than the cost of trying to manage the risk.

    • Second, there may not be any reasonable and practical activities available to manage the risk. For instance, it is possible that there is a risk of your sponsor leaving and a new sponsor canceling the project. However, you may not be in a position to do much about it as long as the current sponsor is in place, and you may just need to leave it and see how events play out.

  • Monitor the risk. In this case, the project manager does not proactively manage the risk, but monitors it to see whether it is more or less likely to occur as time goes on. If it looks more likely to occur later in the project, the team must formulate a different response at a later time. This is a good approach if you have identified a risk that should be managed, but the risk event is far off in the future.
  • Avoid the risk. Avoiding the risk means that the condition that is causing the problem is eliminated. For example, if you find that a part of the project has high risk associated with it, that whole part of the project can be eliminated. The risks associated with a particular vendor, for instance, might be avoided if another vendor is used instead. This is a very effective way to eliminate risks but obviously can be used only in certain unique circumstances.
  • Move the risk. In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For instance, you may identify a risk associated with a new technology. Outsourcing the function to a third party might eliminate that risk for the project team. The risk event is still there, but now some other entity is dealing with it.
  • Mitigate the risk. In most cases, this is the approach to take. Mitigating the risk means that you put in place a set of proactive steps to minimize the likelihood that the risk will occur. If possible you could eliminate the risk by minimizing the likelihood down to zero percent. Another purpose of mitigation is to ensure that if the risk occurs, the negative impact of the risk is minimized. In many cases it may not be possible to totally eliminate a risk event, but given that you have time to prepare, you should be able to minimize the probability of the event occurring, or minimize the impact to the project if the risk event does occur.

These are typical risk responses for negative risks. You can first identify one or more risk strategies and then put the detailed activities in place to effectively manage the risk.

Techniques for Managing Scope

Setting and managing project scope is one of the most important factors for project success. Here are three techniques that will help you be more successful.

Freeze Scope Change Requests Late in the Project

The later scope changes occur, the more they tend to impact schedule and budget. You might think that as long as the sponsor is willing to approve increases in budget and time to make the change, they should be able to do it.

This is normally true – but only up to a point. There comes a time in a project where it just doesn’t make sense to make additional scope changes. That is the time to gain a commitment for a change freeze. Not only are new changes expensive to implement, they are a distraction to the project team.

Depending on the nature of the project, this freeze is usually implemented as the team is getting ready for the “drive to implementation”. At this point, the team is focused on implementing the solution. At that point in the project, scope change requests are not only costly, but they are also very disruptive. The team can lose focus and become mentally deflated. You may find that the next time there is a “drive to implementation” the team will get sloppy and make mistakes, since this would be the second time they performed these implementation activities.

The better approach is to hold these changes on a backlog and deal with them as enhancement requests after the solution is implemented and stable.

Track Valid Change Requests that are not Approved During the Project 

It is possible that the sponsor may not approve scope change requests during the project, but they may be viable requests that can be done at a later time. These types of change requests should be captured on a backlog list. After the project is completed and the solution is moved to the operations and support organization, there may be opportunities for enhancements or a Phase II project.

Do Not Use Estimating Contingency for Scope Changes

One of the steps in the estimating process is to add contingency hours, budget and schedule to reflect the level of uncertainty associated with the estimate. (For instance, if the effort hours were estimated at 5,000 hours, you might add 500 hours for contingency, which reflects a 90% confidence factor and 10% uncertainty.) Once the contingency is approved, there will be pressure on the project manager to use the contingency to absorb additional requirements. The client might say, “Why do we need to invoke scope change management for this 100 hour enhancement. You have 500 hours of contingency built into your estimate!”

The project manager must resist the temptation and the pressure. The purpose of the estimating contingency is to reflect uncertainty in the estimates. There will be plenty of opportunities to utilize the contingency when activities take longer than expected. Do not use the estimating contingency to absorb extra work.


Things to Know About Critical Path

Critical path refers to the sequence of activities that must be completed on time for the entire project to be completed on time. It is an important aspect of your project schedule. Here are five things to know about critical path.

1. Float refers to schedule flexibility

On every project, no matter how complicated, there are always some activities that can be started earlier or completed later without jeopardizing the final completion date. This flexibility between the earliest time an activity CAN be completed and the latest time when it MUST be completed is called “float”.

2. The critical path has no float

Now let’s look at those activities where you do not have the flexibility in the start and end-dates. These activities cannot be completed earlier because they are pending the completion of another activity. They also cannot be completed later without causing all the succeeding activities to be late. All of these activities back up tightly against other activities that precede or succeed them. In other words, the path has zero float.

The critical path consists of the longest sequence of activities that must be started and completed exactly as scheduled. It is the longest sequence of activities with zero float.

3. Why is the Critical Path Important?

If the project is trending late it is very important to identify the critical path activities. Unless you are able to accelerate activities on the critical path, the end-date for the entire project will not change. Applying additional resources to activities that are not on the critical path will not affect the overall project end-date. Your chance to make an impact on the projected end-date relies on your ability to identify and shorten the critical path.

4. The Critical Path May Change

Given that there are many, many paths through the schedule, it’s possible for the critical path to change. For instance, say you have a project with 22 activities over nine months. Let’s assume that there is another path of work that includes 19 activities and takes 8 ½ months. There are two weeks of float on this path. Let’s say one of the activities on the 8 ½ month path ends up taking an extra four weeks. Because there was only two weeks of float in the path, it will now become the critical path and force the entire project to complete in 9 1/2 months.

5. You must sequence activities to understand critical path

The critical path relies on an understanding of the successors and predecessors of each activity. If your activities are not sequenced, the critical path may be calculated erroneously. 

Where Do Project Managers Provide the Most Value?

Not everyone believes in project managers.  Some people say project managers are simply bureaucrats that push paper and don’t provide value to the project. Other’s think they know about useless processes but not about the real work of the project.

There are many fine and capable project managers. However, that doesn’t mean that everyone is competent, or that even the capable ones are perfect. Poor project management can still negatively impact the success of the project.

I think poor project managers are in the minority. Project management is a tough job, but it does not take too long to see what makes project managers valuable. Here is my perspective.

  • There are many reasons why projects are less than totally successful. Many projects are successful based solely on the skills and talents of the project team, but it seems these are in the minority. It seems intuitive that major work initiatives will be more successful if they are planned ahead of time and managed proactively. (Versus projects that are planned poorly and managed reactively.) The person that plans and manages that project is the project manager. So, it seems like the project manager is valuable at a basic level.

  • Some people believe that a good project manager can be successful on any type of project, regardless of whether they have any subject-matter expertise. Other people believe you cannot manage a project without prior subject-matter experience. My belief is that a skilled project manager with no subject matter experience is better than a subject matter expert without project management experience. The project manager provides a value to the project based simply on applying their project management skills.   

  • The project management processes used on a project must be scaled based on the size and complexity of the work itself. Small projects need less rigor and structure. Large projects need more. A good project manager knows how to apply the right processes based on the size of the project. This provides value.

All projects build things. This is the purpose of the project. If you have the best project manager in place, but you are not delivering products the customer needs, you are not going to be successful. Project managers are important because they ensure project deliverables are completed successfully. This is where the real value lies.

So, here is my bottom line. Project managers that know what they are doing, implement proactive project management practices and apply processes scalably can contribute significantly to the success of the project. Do all project managers meet this criteria? No, of course not. Those that do are the real rock stars of project management. If you are a project manager strive to this level of knowledge and performance, and then you too can rock on!

Criteria to Determine Your Estimating Threshold

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

How small should the activities be before they do not need to be broken down further? This is referred to as your “estimating threshold”. For example, if your estimating threshold was 80 hours, you would continue to break the work into smaller entities until all work was less than 80 hours. No work would be left at a higher level.

You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more), any work that is greater than 80 hours of effort should be broken down into smaller pieces. Medium-sized projects (say 1000 effort hours) should have activities no larger than 40 hours. If the project is small (say 200 hours), you should break down the activities into work no greater than 20 hours. Remember that this threshold is an upper limit. You can break the activities down further if you want.

There are two criteria for determining the threshold.

  • Better understanding the work. If you leave schedule activities at too high a level it may not be clear what is required to complete the work. You need to make sure the work is discreet enough that it is understandable and it is clear what is required to complete it. For example, if you assign someone an activity that is 240 hours, there may be a lot of work to do for completion, and it may be confusing. If you assign four activities of 60 hours each (or 6 activities of 40 hours each) it should be more clear what is expected for each piece of work.

  • Better able to manage the work. When you assign work to a team member you don’t know how he is progressing until the due date (or the completion date if it comes first). For instance, if you assign a team member a piece of work that is due in eight weeks, you are not going to know for sure whether the work is on time until the eight-week deadline. Until that time you can just approximate if it appears things are on schedule. However, eight weeks (or longer) is too long to wait to know for sure if the work is on track. A better approach is to break the eight-week activity into four two-week activities. Then you will know after two weeks if the work is progressing on time or not.

It is possible that activities that are to be worked on in the distant future may not be able to be broken down less than the threshold because there may be too much that is unknown about the work itself. The future work can be left at a level higher than the threshold. However, if you leave future work at a high-level, it is still critical to break the work into smaller pieces at least two to three months before you need to start executing the work.

These two factors – understanding the work and your ability to manage the work effectively – should drive your decision on how small to make your activities.

Agile in Practice – Reasons to “Build for Today”

One of the philosophies of Agile Projects is to “build for today.” In other words, you should design, build and test only what is necessary to meet the needs of the user stories that are selected in the current iteration.

In some respects this goes against the intuition of many team members that feel it is more efficient in the long-term if they take into account potential future requirements. The thought is that you should build to support this future functionality “while you are there” and then later when the requirement is actually selected you can finalize the work with much less effort.

In the Agile model this is generally seen as a false tradeoff for four reasons.

  1. First, the time it takes to design, build and test to support future features will mean that you cannot get as much done in the current cycle. You are supporting fewer current, concrete, high-priority requirements in exchange for vague, distant potential future requirements. This is not seen as a good trade-off.

  2. Second, it is possible that this extra, future functionality will never be needed or requested. The customer may have requested this future functionality in a traditional project, but in an Agile project, the difference between “wants” and “needs” is much more focused. Who knows if the extra functionality will make it into a future sprint? The world is full of systems functionality that is written into programs but never utilized.

  3. Third, it is very possible that you may not implement the future requirement correctly anyway. The product owner will not discuss it or test for this future condition. Even if a future requirement seems simple and fully understood, it is possible for misunderstandings and errors to occur. Then you are out-of-synch trying to test and debug problems that should not even be a part of this iteration. Each cycle will also have its own challenges. You don’t need to compound things by introducing problems that are not a part of this release.

  4. Fourth, if the extra functionality is needed in the future, it will have its turn in a future cycle. When the functionality is chosen, the work will be constructed and tested. In an Agile project, you will likely visit the same sections of the solution multiple times. You don’t have to worry about building extra functionality “while you are there” because it is very likely you will “be there” many more times before the project is completed.

This philosophy should be applied for process functionality, performance, security, etc. The “build for today” approach is also an example of “minimally sufficient,” which is another Agile philosophy. You want to make sure that you do everything required to support the customer needs, but no more.