ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs Displaying items by tag: Project management
Project Management Blog
Many people work in competitive bidding environments, where the company generates revenue by winning contracts to complete projects and deliver products. Ideally, you would estimate the work on these project as best you could and with an acceptable level of risk.

Unfortunately, you may find that your best estimates are being ignored by management or the sales organization. The problem in that case is that if you win the business, you are probably on the hook to deliver the same level of functionality and quality, but with a significantly impaired budget.

This type of scenario puts the project team in a difficult situation. In this case, you are asked to estimate a piece of work. You deliver the estimate as requested, but then management or the sales people ignore the estimate and make up their own, which you then have to use. This is frustrating because it makes it hard to know the rules and the expectations.

If the pre-defined processes were always followed, life would be so much easier. But the hard part of project management is usually dealing with people issues. It is important to consider the other side as well. The salespeople must feel that they need to reduce the estimates to have a chance at the business. This could be to cover weaknesses in their sales processes, or this may be a fact of life if you are to get any projects at all. Of course, if you have no sales, you have no job.

The following are areas that could help improve the estimating process.

Open a Dialog Regarding Estimating Expectations

Talk to your managers and the sales organization about your team’s frustration, and explain your perspective. Note that they asked you for an estimate, you provided a realistic estimate, and they cut your estimate. This puts you in a position where you cannot deliver what the customer wants for the budget on which they agreed. Ask them for their suggestions in helping to constructively address the situation. You may find, for example, that they do not trust your numbers, in which case you can work with them on the level of detail required to gain their confidence. See if they can help you solve this problem so that both groups are more comfortable in the future.

Negotiate on Functionality

Normally, you could try to reduce some functionality to deliver within a lower budget. This may not be an option when you are dealing with a customer on a fixed bid. However, talk to sales and your managers about any areas of scope that can be reduced or removed from the proposal before it is presented to the customer. If this is a possibility, then there may be a way to commit to less while also being able to deliver the reduced scope at the price needed to win the business.

Look for Process Improvements

There may be things you can do to reduce the cost of development. Can you hire less expensive resources? Can you use new techniques that will allow faster delivery? Are there some testing techniques that would result in less rework? Can errors be caught earlier in the life cycle? You may be able to find ways to deliver the project for less effort and cost through process improvement.

Strive in the Challenge

Get yourself and your team fired up for the challenge of delivering within the reduced budget. You can still prepare a reasonable estimate, but then try to raise the level of team productivity to deliver for less effort and cost. This may be something that can be a challenge in the short to medium term, but it will not work for every project over the long term.

Play the Scope Change Game Well

In some instances, a vendor bids low on the initial contract and then tries to recover costs through scope change management. In other words, they try to force as many features as possible through scope change management, and in each case get more budget money. If the contract and requirements are written loosely, you may find that you can generate significant additional revenue through scope change management, while in fact delivering nothing more than what the customer initially had in mind. On many fixed price contracts, the revenue associated with change requests exceeds the price of the original estimate. Some project managers could bid a project at zero dollars, and then make the entire project look like scope change requests.

Pad the Estimate (But be Careful)

One option I mention but do not endorse is to pad the estimate. For instance, you could increase your estimates by 10% so that if your budget is cut 10% you can still deliver. The major disadvantage here is that the additional dollars in the estimate might make the difference between winning and losing the business. It also introduces deception into the process, and that is not good.

Leave

If this is the nature of the environment you work in, and if you don’t like the business model you work under, you may have to break the stalemate and go somewhere else where you can be more successful.

Summary

Starting a project with less money than you think you need is certainly uncomfortable. On many projects, it would be a recipe for failure. If you are in that situation often, and if it is done on purpose, morale might be bad and it can be difficult to excel. In most situations you have three options – fight for change, adapt, or flee. The options above cover all three of these alternatives.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Tuesday, 04 November 2014 17:04

Managing Projects with Unrealistic Deadlines

If you are a project manager dealing with what you perceive to be an unrealistic deadline, you will first want to discuss this with your manager and see if there are any factors that are driving the project deadline that may be unknown to you. Sometimes the person who gives you the deadline seems like the bad guy, but see if you can understand the motivation. For instance, there may be a business activity that is driving the deadline. There may be some event occurring that this project needs to support. Or, your project may be one of a number of initiatives that need to come together at a specific time. It does not necessarily make your challenge any easier, but you may find that by better understanding the reason for the deadline, you may have an easier time getting yourself and your team members motivated to try to achieve it.

On the other hand, if the deadlines seem arbitrary and are not the result of some other business driver, then you should find that out as well. Sometimes managers set arbitrary end dates just to provide what they consider to be stretch objectives. However, if the manager is not careful, there will be a time when there is a firm business justification for an aggressive end date, but no one will believe it.

Once you understand the motivation for the deadline date, there are project management techniques that can be utilized to increase the chances of success and better manage expectations.

Try to Adjust the Triple Constraints of Time, Cost and Scope

All projects require some time and cost to create the deliverables agreed to in the project scope. When one of these constraints is out of balance, at least one of the others needs to be adjusted to get them back in alignment. For instance, if your budget is cut, you need to reduce the scope or increase the time to deliver.

If you find that the time constraint is not in alignment with cost and scope, talk to your manager about increasing the resources that are available for the project. Adding resources to the project makes the cost go up, but may allow you to hit the deadline. Also talk to your customer about reducing the project scope. See if there are features and functionality that they can live without for now so that you can deliver the project within the deadline specified.

Utilize Risk Management

When you start a project, the first thing you need to do is plan. One aspect of the planning process includes identifying risks and putting plans into place to mitigate the risks. In your case, if you don't think you can hit the imposed end-date, now is the time to say something. When you do, your manager and your customer start to hear that the end-date is at risk before the project even begins. As part of the risk identification, you can ask the project team, your customer and your manager for their ideas on how to mitigate the 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.

Utilize Scope Management

On many projects, you start with an aggressive delivery date, and then the project gets increasingly behind schedule because the project manager does not effectively manage scope. Then you end up having even more work to do by the deadline date. Disciplined scope management will ensure that you only have to deliver what was originally promised, and that any approved changes are accompanied by a corresponding increase in budget and timeline.

Aggressively Manage the Schedule

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. If early due dates start to slip, you are going to be in trouble early. As you monitor the schedule, treat missed deadlines as issues and work hard to solve the reasons behind the slippage. Again, get your team, management and customers involved. If your customers are causing delays, get more accountability from your business managers for helping to resolve project resource problems. Again, if the problem cannot be resolved perfectly, at least you are continuing to manage expectations.

Look for Process Improvement Opportunities

Lastly, take an honest look at your schedule and your approach for executing the project. Talk to your team, customers, and manager about any ideas they may have for speeding up the project. This will get everyone thinking about being part of a solution. For instance, if your manager insists on having the project completed earlier than the date you have specified, ask him what techniques he could suggest to achieve the earlier end date. Document any suggestions you receive. Show your customer the project plan as well. If you are not achieving the end date they expect, ask them for ideas on how to shorten the project. See if they can help you come up with a solution to the scheduling problem, instead of just passively waiting for the project to be completed.

In addition, perform a self-evaluation of the project schedule and see if there are ways that you can reduce costs and cycle-times. For instance, are there some different development techniques that you could try that might decrease the end-date? Could you utilize a Joint Application Development (JAD) session to gather requirements more quickly than traditional interviewing techniques? Look at how you currently deliver projects and how you manage them to see if there are ways that you can accomplish the project objectives for less time and cost.  

Summary

In summary, 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. First, see if you can balance the early deadline by increasing resources or reducing project scope. Second, proactively manage risk, scope and the schedule so that you can better manage expectations and have the best chance for success given the constraints you are under. Third, work with your manager, customer and project team to evaluate how you are executing the project. You may discover ideas and techniques that will allow you to deliver the project more quic that you might have first thought possible.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
When a project begins, you must gain agreement with your customer on exactly what you are creating. At a high level, this agreement is reached when the Project Charter is approved. At a low level, the agreement is reached through the approval of the business requirements. Once these two documents are approved, you have enough information to proceed through the remainder of the project.

However, change is inevitable. There are two reasons. First, it is almost impossible for anyone to define ahead of time exactly what the final solution should look like, and so the requirements may change as the solution evolves. Second, overall business conditions change over time. Some of this business change will force changes to the project scope in ways that are not known ahead of time.

So, what do you say when the inevitable changes start to come in? If you say yes without understanding the consequences to the project, you increase your chance of failure. If you say no, you may introduce conflict with the customer, and run the risk of delivering a solution that does not meet the customer’s needs.

Don’t Take It Personally – Use Your Process

When introduced with changes to the project, the best response is to follow a scope change request process. This process should include understanding the business value of making the change, as well as the impact on the project budget and schedule. You can then take this information to the project sponsor (or their designated stand-in) for an approval decision. Scope change management is really the art of letting the sponsor make the decisions once they understand all the facts and implications.

You should establish scope change procedures based on the size of the project. For small projects, you do not need to worry about scope change very much. The project will likely start and end before the business can change much, and most of the requirements are probably fairly well-known. The project manager can quickly evaluate a small change request and work with the sponsor to determine if it should be accommodated.

For larger projects, scope change is a big deal and must be managed accordingly. The entire team, including the customer, must understand when a scope change request is being made. The request should be documented and sent to the project manager. The change is then analyzed and the resulting information regarding the change, the benefit, the cost, and the impact of not accepting the change are brought to the attention of the project sponsor. The project sponsor then determines whether to accept the change. If the change is approved, then the budget and timeline are changed accordingly. If the change is not approved, it is noted as such and the project continues on its way. The funny thing is, if you let the project sponsor decide whether to accept a scope change, he will usually turn the request down. The sponsor understands the need to deliver something, even if it does not meet 100% of his needs. The final solution can be refined over time. In fact, the sponsor typically has a lot less patience for scope change requests than the project manager, and this will eliminate frivolous and marginal scope change requests immediately.

Summary

All projects need to first gain agreement on the scope and the business requirements before scope change management will stick. After that, the key to scope change management is to recognize that it is the process of letting the customer make scope change decisions. The project manager needs to make sure that the appropriate information is presented so that the sponsor can make an intelligent, fact-based decision. Many project managers do a poor job of managing scope because they do not want to offend the customer. However, that should not be a part of the equation at all. Instead, the project manager’s job is to make sure the scope change management process runs effectively, and that the project sponsor has the information necessary to make the best decision possible on whether the scope change should be accepted.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
A lot of project managers can relate to the comment that it seems like the project manager does a lot of administrative work. However, administrative work is in the eye of the beholder. What one person sees as administrative work might be considered controlling the project to another person.

A quick overview

Let’s do a quick overview to make sure everyone is on the same page. In general, the project manager is responsible for the overall success of the project. He or she leads the team through a definition and planning phase, and then monitors and controls the project until it successfully (you hope) concludes. This would include managing scope, issues, quality, etc. Notice that performing administrative work is not a part of that simple definition.

Don’t forget people management

The project team may or may not report functionally to the project manager. The project team may report to a different manager for things like performance reviews, while reporting to the project manager for their work. In other companies, the functional reporting relationship goes directly to the project manager. However, in either case, the project manager must also perform people management responsibilities. This includes soft skills like listening, providing feedback, being empathetic, providing leadership, etc. There are many instances of project managers who are unsuccessful based solely on their lack of interpersonal and people management skills.

What exactly is administrative work?

You have quickly seen that the project manager has process management and people management responsibilities as a part of the general project management role. Now, consider administrative duties. The first question to ask yourself is exactly what is administrative work for a project manager? Part of the answer has to do with how you feel about the various responsibilities that a project manager has. Let’s look at a few and see what you think.

1.      Status reporting. You can tell a lot about the mindset of a project manager based on how he looks at status reporting. Many project managers think that status reporting falls under administrative work. Others believe that status reporting falls directly into the responsibility of a project manager to proactively communicate status. When in a project management role, you should plan out the best way to deliver status updates to your stakeholders as a part of a Communication Plan. Depending on your point of view, this may or may not be considered administrative work. It might just be considered a fundamental part of your project management responsibilities.

2.      Updating the schedule. Some project managers hate to update a workplan, and think that this is an administrative burden. What do you think? To many, updating the schedule is one of the core responsibilities of the project manager.

3.      Completing a Project Charter. Many project managers just want to get going and start the work. To them, planning is an afterthought, not something that should hold up work on a project. Others think that if the project manager views the chartering process as administrative work, it implies a certain lack of project management maturity. There is always a legitimate question as to how much planning is required, but there never should be a question about doing it or not doing it.

4.      Updating project logs and forms. Many projects have forms that they use to request scope changes, or perhaps the project manager is keeping track of issues on an Issues Log. Are these administrative tasks, or are they the valuable tools of a project manager?

5.      Performance reviews. If you have project team members that report to you, you undoubtedly have some paperwork to do around the performance review process. This has a direct tie to your people management role. Would you consider this administrative or not?

Ask again – what is administrative work?

With this in mind, you should again help define administrative work. You could probably come up with times when the work might be administrative. For instance, if your organization requires some type of report that is not project-focused, you might say that it is administrative. You may also participate in other non-project related activities such as interviewing new employees, filling out surveys and responding to management requests for information.

Summary

Some project managers think that anytime a document is involved, it is an administrative task. Some might go as far as to say that anything that requires writing (or typing) is administrative. But is that really the case? This response should give you some more insight into the project management role. Much of what might appear to be administrative work is really the direct input or output related to project management or people management. Project managers can master this aspect of their job and relegate it to a smaller percentage of their time. However, if you have an aversion to this type of work, project management may not be right for you.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Tuesday, 23 September 2014 21:07

Turning Around a Dysfunctional Project Team

Every project faces certain obstacles, but sometimes it may seem that the problems are insurmountable. If you feel like your chances of success on a project are unclear, you could look at the situation in two ways. One way is to consider yourself on a train that is heading for a certain wreck. If you are thinking of the project in this way, then the best actions to take may be to minimize the damage, see what can be salvaged and try to keep from having the company throw too much additional money on top of what has already been spent. You might be considered a hero in some circles if you recommend canceling the project.

On the other hand, there are project managers that are known as turnaround artists, and they love to take over projects like yours. In fact, many of them like the worst projects best of all. There are people like this at all levels, including CEO’s whose expertise lies in turning around companies that are in terrible shape.

The project may be need to be completed regardless of the cost in terms of dollars and human relationships. Let’s assume for now that you will try the latter course of action – the project turnaround.

The first thing you want to do is assess the current state of the project. This includes the project schedule and the project team dynamics. Your response to the project team problems will depend on where you are with the schedule. If you only have 30 days of work remaining on the schedule, you will have less ability to make an impact. In this case, the best course of action may be to try to motivate the team for the final push and watch the schedule like a hawk. 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 to replan the schedule to deliver on a new realistic timeframe. Any plan is going to include the following items.

Communicate well. Have you been on a project where the project manager is a poor communicator? This trait usually results in a miserable project experience for everyone. Teams with poor morale tend to have poor communication channels. Don’t let rumors 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. There is hardly any time when over-communicating is a problem. In your case, it can do nothing but good.

Praise and compliment. When people on your team do a good job, make sure they know it. People do not 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. Another cause of negative morale is poor or no positive feedback or recognition.

Set clear expectations. People like to understand what is expected of them so that they know the challenges they need to meet. They want to see the dragon and slay it. Make sure you give clear instructions when you hand out work so that people understand what they are expected to do. When you hand out work assignments, give a deadline date. When a team member is creating a paper deliverable, like a testing plan, give guidance on how it should be prepared.

Don’t overcommit your team. As you try to improve morale, you also need to be careful not to overcommit the team. Determine what exactly is required to finish the project, and remove anything that is extraneous or can be done after implementation. Make sure you manage scope tightly, and try to defer all changes until after the original project is completed. 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.

Summary

These are some ideas for turning the project around. First, make sure you understand where you are in the schedule so you know how much time you have to make significant changes. Also, 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. There are many areas to look at as a part of repairing damage to the project team. Communication, timely performance feedback and clear expectations will be a part of every turnaround plan. Then, go out of your way to start building some successes – even interim ones. These general ideas, as well as others that you will identify, will give you a fighting chance to turn things around. Who knows - if you are successful and you enjoy the challenge, you might be known as a turnaround artist within your own organization!

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Tuesday, 09 September 2014 20:37

"Managing" Outsourced Projects

"Managing" Outsourced Projects

Outsourcing of project work is more common today than ever. However, even though you outsource the work, you cannot completely outsource your obligation to make sure the project is progressing smoothly. If all goes well with the outsourcer, you do not have much work to do. Unfortunately, in many instances the outsourcing vendor does not meet expectations. If that happens, you want to know about it as soon as possible. For the purposes of this discussion, let’s assume that your company has outsourced a project, or a portion of a project. Your company has also asked you to manage the relationship to ensure the vendor performs as expected.

Many people are not sure what they should be doing when they are asked to manage an outsourcing relationship. Part of the uncertainty is because some of the project roles are reversed when you outsource work to a third-party. On a normal internal project, the project manager assigns the work and manages issues, scope, risk, quality, etc. The project manager makes sure work is done on time and the project is progressing as it should. He or she is held accountable for the success of the project. Other people perform a quality assurance role to make sure that the project progresses as it should. A formal quality assurance group may do this, but it is more likely that the sponsor and the manager of the project manager perform this function. They are not interested in knowing all the details of what is going on, but they need to ask the right questions to feel comfortable knowing that activities are progressing as they should.

On an outsourced project, the roles are still in place, but different people perform them. If the work is truly outsourced, the project manager for the vendor should be the one who is worried about the details. The vendor project manager is planning and assigning the work, and managing issues, scope, risk, etc. In this situation, even though you may be asked to "manage" the outsourced project, you really take on the quality assurance role. You need to ask the right questions to make sure that the vendor is doing his or her job correctly. You do not necessarily need to know all the details of how he or she is managing and executing the project, but you have to feel comfortable that the project is progressing as expected.

What to Look For at the Beginning

First, look for the up-front deliverables that you expect from all projects. For example, is there a project definition document? You need to make sure that the vendor team has defined the project correctly and to your satisfaction. You should approve this document. The vendor must also have a project workplan. As the project moves forward, you must be aware of the key milestone dates, and there should be a formal checkpoint to ensure that the deliverables produced up to that point are complete, correct, and on time. You and your sponsor should formally approve the important ones. Depending on the nature of the project, you may require regular status meetings and formal status reports. The questions you should ask at the beginning of the project include:
  • Has a project definition (or similar document) been approved by the appropriate stakeholders and managers at your company?
  • Is there a contractual agreement that spells out the expectations of both parties in terms of deliverables to be produced, deadlines, payment schedule, completeness and correctness criteria, etc?
  • Has a comprehensive project workplan been created?
  • What project management procedures will the vendor use to control the project?
  • Has the vendor been clear on what resources will be needed from your company and when they will be needed?
  • Have milestones been established to review progress so far and validate that the project is on-track for completion?

Ongoing Questions

As the project is progressing, you must continue to ask questions to determine the current state of the work. You may have status meetings weekly, but there should be a formal quality assurance check at the end of every agreed-upon milestone. The types of questions you should ask at every milestone include:

  • Have the deliverables specified in the project definition been completed up to this point?
  • Have the appropriate deliverables been agreed to and approved by the company?
  • Can the vendor clearly explain where the project is vs. where it should be at this time?
  • Will all the future deliverables specified in the project definition be completed?
  • Are issues, scope, and risks being managed as stated in the project management procedures?
  • Should the contract or project definition be updated to reflect any major changes to the project?

Once you understand your role on the project, it is easier to ask the right questions to make sure that everything is progressing as it should.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .

Published in Blogs
There are almost as many varieties of PMO as there are companies. There are strong PMOs and weak PMOs. There are some that have many responsibilities in the organization and some that have only a few. Some companies rely on the PMO to be responsible for all areas of project management and project execution. Other companies only want the PMO to provide a consolidated reporting view of all the projects in the organization.

Before you can jump in and start up a PMO, you must first define what the PMO will look like. Without this foundation, all of the other work you do will be in jeopardy.

The place to start creating your PMO is through a formal organizational definition. The value of defining a logical organization is twofold. First, you gain clarity and agreement on what you are doing and why. This information is communicated to clients, stakeholders and your own staff so that everyone starts off with a common set of expectations. Second, this exercise provides a framework for the PMO to guide decision-making in the future. For instance, you would not want to undertake any projects that did not help you achieve your organizational objectives. Likewise, major decisions can be evaluated based on whether they fit into your strategy.

Building a Logical Organization

The term "logical organization" means that when the definition is complete, the organizational structure will only exist on paper. Once the logical organization is defined, you still need to actually staff the PMO at the right level to support the logical organization. Many companies have the expertise to perform this definition by themselves. However, defining missions and strategies is not something that you do every day. That is why consultants are sometimes brought in to assist. There are consultants that specialize in these organizational assessments. They can facilitate the definition process and make sure that the resulting logical organization provides a firm foundation for the subsequent staffing and project execution.

The following major components are used to define your logical PMO.

Mission. Describes what the PMO does, how it is done, and for whom. It is a very general statement, usually aligning the PMO to the value it provides to the business. An example of a PMO mission statement is "The Acme Project Management Office (PMO) implements and supports project management methodology to enable our organization to deliver projects faster, cheaper, with higher quality, and within estimates and expectations."

Strategy. There may be many ways to achieve your mission. A strategy is a high-level set of directions that articulate how the organization will achieve its mission. Defining a strategy also helps get the PMO aligned in the same direction as strategies in the rest of the company. Strategy defines how you will do things over the long-term - say three years - and is used as an overall framework for the more detailed tactical decisions that are made on a month-to-month and day-to-day basis.

Sponsor. All organizations do not have a sponsor, but a PMO typically does. In this respect, a PMO is similar to a project and, in fact, many PMOs are established with a project. The sponsor is the person responsible for the PMO funding, and in many cases the sponsor is the manager that the PMO reports to. Sponsors are important for all initiatives, but they are absolutely critical for a culture change initiative such as this.

Clients. Clients are the main individuals or groups that request and utilize the products and services your organization provides. (These people may also be referred to as customers.) While there may be many stakeholders (below), it is important to recognize who the clients are. They should be the ones the PMO focuses on to help them meet their project and business objectives.

Stakeholders. These are the specific people or groups who have an interest or a partial stake in the products and services your PMO provides. Internal stakeholders could include organizations you work with, but who are not directly under the PMO umbrella. External stakeholders could include suppliers, investors, community groups, and government organizations.

Objectives. Objectives are concrete statements describing what the PMO is trying to achieve in the short-term, perhaps up to one year. The objectives should be written at a low level, so that they can be evaluated at the end of the year to see whether they were achieved or not. A well-worded objective will be Specific, Measurable, Attainable/Achievable, Realistic, and Timebound (SMART).

Products / Services. Products describe tangible items that the PMO produces, and are typically produced as the result of a project. Services refer to work done for clients or stakeholders that does not result in the creation of tangible deliverables. Services provide value by fulfilling the needs of others through interaction with people. The PMO achieves its objectives through the creation of products and the delivery of services.

Transitional Activities. Transitional activities are the specific activities and projects that are required to implement the physical PMO. If the PMO is new, these activities describe the work required to build and staff the new organization. This does not imply the creation of a full workplan, but it includes the immediate activities required to get you to the point that the PMO workplan can be put into place.

There are other aspects of the organization that can be defined as well, including the PMO vision, principles, goals, skills, roles, and responsibilities.

Summary

A PMO should be established based on a need to help the organization in project management and project execution. There are many ways that a PMO can be established. The correct way for your company can be determined with an exercise to create a logical organization definition. When you have a consensus on the definition, the PMO has a much better chance of success and of meeting sponsor, client and stakeholder expectations. Once the logical organization is approved, the staff can be put into place to build the physical organization.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Wednesday, 13 August 2014 19:36

Getting Your Priorities Right

Most managers establish priorities and use them for guidance when making decisions. However, some say they have priorities, but they do not ever reference them. This is not prioritizing - it is wishful thinking. Unfortunately, success is rarely built on wishful thinking.

Why prioritize?

Without priorities, only the urgent work gets done and one may never get around to any activities that are merely considered important. Effective managers have always known that priorities help them to focus on tasks that make a difference. They provide purpose, direct energy, and drive action. They also encourage leaders to set their own agendas.

Successful businesses, corporations and other organizations spend considerable time developing a mission statement and defining goals because these activities are priorities. They identify what's valued, define what the organization is all about, and underscore where it is going. They minimize confusion and maximize consistency.

Don’ts

Setting priorities is not guesswork or magic. It's mostly a matter of common sense. Avoid identifying inappropriate priorities by never prioritizing something just because:
  • It's what you like to do most.
  • It's fun.
  • It's the easiest and quickest thing to do.
  • It's just always been a priority.
  • It just happens to be at the top of your to-do list.
  • It promises an immediate pay-off.
Dos

True priorities are those jobs, tasks, responsibilities or functions that keep people on track and guide everyday actions toward desired ends. A true priority can be identified when:
  • It's a key part of your job description.
  • It closely matches the mission of the organization.
  • It moves you toward individual and organizational goals.
  • It yields the biggest payoff.
  • The boss says so.
  • Only you can do it.
  • It's what you do best.
Anyone can identify and give lip service to high-sounding priorities. Priorities make a difference only when acted upon. Sorting out priorities can empower managers to consistently do what's important, not just what's next. However, it doesn't happen by chance. It has to be a conscious choice.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
When you mention methodology to many project managers, their eyes roll upward as if to say “Oh no, something else to get in the way of getting my project done on time.” The term methodology often has a bad image, maybe partly because the word itself is long and mysterious.

However, all project managers use a methodology. The term just refers to the processes, procedures, templates and practices you use to manage your project. A better question to ask is whether you use a personal methodology based on experience, or a formal methodology that was defined by your company or purchased from a vendor.

Use Formal Processes on Large Projects

One of the reasons why project management methodology is not utilized as effectively as it should be has to do with scalability, or utilizing the right amount of structure and process based on the size of the project. For example, on small projects, you can get by with very reactive project management. You might manage scope loosely, because the chances of receiving a scope change request are small, and the impact to the project is typically just incremental. Many project managers are not very good at managing risk because small to medium sized projects don’t usually have much risk. In many cases, communication with the customer just means telling them when the work is complete.

Those same processes will usually fail miserably on large projects. Let’s say you have 50 people and a five million dollar budget. (In some shops even that is considered small to medium!) You have to manage the project proactively. Issues will arise that are too complex and too numerous to manage by the seat of your pants. Scope change on large projects is usually a given. If you aren’t careful, your five million dollar project will turn into ten million by the time it is done. You need to see risks coming and manage them, or your project will be in deep trouble. Communication with your stakeholders needs to be ongoing, multi-faceted and planned ahead of time. In other words, this is the time when you will be glad to have a full-featured project management methodology to rely on.

Apply Less Extensive Processes on Small Projects

Let’s take the other side now. The project starts. You create a 15-page Project Definition document and workplan. You gather your team and look for project risks. You expect weekly status reports from your team members and, in turn, send weekly updates to your customer. Scope change requests require extensive documentation and approval. Does all of this sound good so far? Well, it shouldn’t. The entire project is only 200 hours and three weeks in duration.

When this scenario happens, project managers see methodology as burdensome, cumbersome and not adding value to their project. Usually that means that the methodology was defined at a level necessary to manage large projects, and has not been appropriately scaled for smaller ones. The project can still be completed successfully under these conditions, but it introduces inefficiencies and frustration. The project costs more than it should and takes more time than it needs to. And remember, there are usually many more small to medium projects in your organization than large ones.

Methodology is Your Friend

As was said up front, the best answer is to apply scalability and common sense to your project management methodology. When a project starts, the project manager and project team need to go through the standard methodology and scale it to the level needed to manage your particular project. If your company went through this exercise already, there may be pre-existing guidelines that you can use based on the project size. The basic philosophy you should follow is “large methodology for large projects – small methodology for small projects.”

Let methodology work for you, not the other way around.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
The Capability Maturity Model (CMM) describes a continuum of characteristics based on how well your company or organization follows common and repeatable processes to get your work done. The low end of the scale describes companies without repeatable processes, where much of the work is chaotic and ad-hoc. The highest end describes companies that use defined and repeatable processes, collect metrics to help them continuously improve their processes, and look for creative ways to do things better on an ongoing basis.

The CMM was developed from 1984 to 1987 by Watts Humphrey and the Software Engineering Institute (SEI). The SEI is a part of Carnegie Mellon University. The work was funded by the US Department of Defense (DoD), which was originally looking for ways to compare and measure the various contractors that were developing software for the DoD.

Although the SEI continues to enhance and expand the scope and breadth of various CMM models, the primary focus for most companies continues to be the software development world.

The five stage CMMI model

There are some slightly different interpretations of the CMMI model. Some companies have also identified their own proprietary versions of the CMMI process. However, in general, there are usually five defined stages.

(1) Ad-hoc / crises. Your organization has few common processes. The success of your projects depends on the strength and skills of your people. The organization provides little in a supporting environment to help make all projects successful. Most companies are at this level, although some companies say half-jokingly that they are at a 0 or -1 level.

(2) Standard project management. Your organization has implemented standard project management processes. You are trying to establish a baseline foundation upon which to improve further in the future. Most companies that start down the CMM path are trying to reach this level.

(3) Standard lifecycle processes. You are trying to achieve standardization in your development process similar to what you did for project management in level 2. This includes common and repeatable software development processes, deliverables, tools, etc.

(4) Managed feedback. You collect metrics on all aspects of your project management and development processes. You have a repository of metrics and key learnings on historical projects that can be leveraged by new projects.

(5) Optimizing / continuous improvement. You have a closed loop of process execution, measurement and continuous improvement. You continuously use measurement, feedback and creativity to optimize your processes.

Is CMMI right for you?

Just as there are real benefits to reusing common program components, there is also value in reusing common processes. Why should every project manager in your company struggle over knowing how to define a project and how detailed the workplan should be? Why should project managers struggle to understand how to effectively manage scope, risks and quality? These are not new concepts. They should all be defined well on an organizational level and then reused by all project managers.

You can use the CMMI model as your guide as you try to implement common processes. You don’t have to start from level 1 and jump to level 5 in one year. The CMMI scale is a journey. Most companies only want to start by moving to step 2. However, even that short jump is not without pain. In many respects, implementing common project management processes is the most difficult part of the journey. In many organizations, this is the first time people will be asked to follow a common set of processes, and many won’t like it. If you can successfully get to level 2, then you should have already established the paradigm shift that will make the transition to level 3 a little easier.

Summary

Many companies are seeing that they can drive business value by implementing good, reusable processes throughout their organization. The Capability Maturity Model provides a framework that companies can use to measure themselves on a standard 1 - 5 scale. Most companies today are at level 1 and would love to get as high as level 2. Most managers and most organizations realize that they should have common and repeatable processes There is definitely pain involved. There is pain involved with all culture change initiatives when you ask people to change how they do their jobs. However, the pain is worth the gain if your company can stay focused while the culture change is taking effect.

Published in Blogs

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 548 guests and no members online

Got something to say?