Microsoft has published another article of mine on its TechNet site. “How To Cancel a Project Without Cancelling your Career” talks about the challenges we’ve seen with organizations who try to deploy Project Portfolio Management or Stage Gating.  If you can’t slow down, pause or cancel a project then the value of Stage Gating becomes quite questionable.  The article will be of interest to project and portfolio managers of course and those who are managing a Project Management Office but will also be of interest to timesheet managers and TimeControl Administrators as the data from how a project is actually progressing often comes from a project oriented timesheet system.

For many in the project management industry, the idea of cancelling a project is extremely difficult in part because the nature of Project Managers attracts personalities that don’t give up easily.  So finding out that there can be a positive impact on the organization by cancelling a project can be welcome news.

You can find the article on the Project Server 2010 0r Project Server 2013 pages of TechNet in the “From the Trenches” column or go to it directly at www.microsoft.com/en-us/download/details.aspx?id=36430. I hope you enjoy it.

Project Management systems – it’s about deployment. Sure, there are lots of functions to consider and everyone wants to know your “methodology” but if you are committed to having projects fit into a an organizational system, it all comes down to deployment. Can you assemble a system that will actually be accepted and used by the end-users who will have to use it. Deployment includes all of it: developing the concept, buying or writing the system, installing it and configuring it of course and, most importantly, getting acceptance from the end users who must populate it with accurate and appropriate data.

Over the next few issues of PM Times we’ll be looking at how to deploy a project management system. We can’t of course, give you a complete course in the few paragraphs we have here. That would take a book. We can however, raise some of the key issues and give you some food for thought in dealing with whatever your current project management system environment is today. Whether you’ve got a well established project management system or if you’re just getting started, looking at how your system should be deployed is key to its success.

In this issue we’ll look at establishing requirements for a project control system. In the next issue we’ll cover creating the deployment plan. The next issue will cover training and finally we’ll look at integrating your pm system with other elements of your enterprise.

Requirements of a project management system
It used to be hard enough to set the requirements for a pm system for the organization. Internal experts and sometimes external consultants would congregate and, after extensive interviews with staff and management would go to the market to see what might be available. From the myriad dozens of potential products, the selection team would make a short list and vendors would troop in to display their wares. With luck, the selected system would meet most of the “must-have” requirements and would also squeeze into the budget.

The pace of change in today’s world makes one nostalgic for those simpler, kinder days. Imagine that five years ago there were perhaps 4,000 organizations who had ever heard of the World Wide Web. Now, some 4,000 new domain sites are registered every day. Two years ago, Java was something you had with your donut in the morning. Now, it is on the must-have list of every project management systems requirement.

What hope is there of setting appropriate requirements for a project management system your organization when technology upon which those requirements must rest is changing faster than you can even complete your analysis.

Well, it’s not as bad as you might fear. First of all, forget for a moment about technology. Your search should focus instead on who needs access to the system and, once they get it, what they’ll want to do. The great thing about the proliferation of Microsoft Project is that it has given us a good benchmark to use in describing functionality to end-users. A little thought about your own project management process here, at the beginning of your implementation will be the highest leveraged effort of the entire exercise.

Work on some of these questions:

• Who has access to the raw data to create new projects and to update existing ones? Should they have direct access to the project management system? What benefits would they gain from direct access? What benefits would the organization gain?
• What is the project management skill level of the projected users
• Who receives now and who will receive the output of the project management system? What reports will they need? How will having that report or data make them more effective? Is there an actual purpose to the reports they are receiving now?
• What lack of project-oriented information or analysis is hurting the organization? What impact would the availability of this information have?
• Who will champion the project management system? What is their authority? Who at the most senior level of the organization is sponsoring the initiative? What are their expectations? Are they achievable?
• Are there external influences in the implementation of this system (e.g. contract requirements)? What are they?
• What other systems will the pm system need to integrate with? Are these systems open enough to integrate? Will the system need to depend on third-party interfaces?

Once you’ve answered some of these questions you can start looking at some of the key building blocks in creating a project management system which will be acceptable to multiple users across your organization. Concentrate on some of the following factors while looking for potential vendors of expertise and systems:

• Suitability to purpose. Ask the vendor what experience they’ve had with your type of industry. Get references and (don’t forget!) call them!
• Flexibility, flexibility and (did I mention this?) flexibility. An “open-architecture” system will be one which can be easily enhanced and upgraded and modified from one use to another. This is key when technology may change faster than your projections.
• Multiple levels of interface for multiple types of user. Sorry, one size does not fit all. Many enterprise-wide vendors will have flexible interfaces or multiple products.
• Open data architecture. “If you can get at the data, you can do anything.” is a bit of an overstatement but key to interfacing with other systems.
• Keeping your options open is key to success in the deployment of a project management system. Until the next issue when we look at your deployment plan, I’ll leave you with this thought from Napoleon Bonaparte: “A battle plan lasts until contact with the enemy.”

A number of years ago I was privileged enough to listen to Ken Mattingly give a keynote address to a room full of project managers. If his name doesn’t ring a bell, think of the movie Apollo 13. Ken Mattingly was the astronaut played by Gary Sinise who had to stay behind because they were sure he would get the measles while enroute to the moon. Mattingly is now Rear Admiral Mattingly and I was eager to hear what he had to say about project management. When he opened the floor for questions, someone asked him if he could give his definition of project management.

“Sure,” he replied. “Project management is doing a specific thing within a specific time with insufficient resources.” We all laughed but I scribbled it down.

It’s almost universally true. After all, if you had more than enough resources and unlimited time, who would need project managers or project management? Lots and lots and lots of people would work on the project until it was done whenever that was.

Everywhere I go, project resources are overloaded and project managers struggle to allocate those resources on the work that they have committed to accomplish.

In a multi-project, matrix organization, everyone wants their project to be selected and approved. In a 2006 survey done by UMT for Microsoft, the majority of organizations polled reported that they selected projects for approval based on their individual merits only rather than comparing them against the merits of other projects. In fact, this method was more than 50% more popular than any other answer.

Not only do project sponsors want their projects approved, but once they’re approved, they want them to be done first, as the highest priority, before any other project is undertaken.

That is a lot of pressure towards a resource management crisis.

The result?

This:

I see this picture all the time at the clients I visit and when you’re as used to it as I am, it doesn’t take too long to interpret. The blue bars represent resource capacity. The red bars represent resource requirement. In any period where the red bars exceed the blue bars, the resources are overloaded. In this example which would be taken at the beginning of January and looking forward to the next 12 months, the resources are overloaded in January through June. Then the resources are under loaded from July through the end of the year. If we look for a moment or two longer at the height of the bars, we can see that the requirements in January through April are overloaded by about 300%.

This is not going to be fixed with a little overtime and some elbow grease. This overload is unfixable. It was caused by starting too many projects within this period and it’s a fact that they won’t happen when they’re planned. And yet, if I look at the end of the year, it is clear what will happen here. The underloaded months will take the projects which are sure to be delayed and by the end of the year most of this work will be accomplished.

If you’re reading this and saying under your breath “How can that guy see our internal data,” don’t worry. The good news is, you’re not alone. The bad news is, you’re not alone. This is a very common scenario.

Now, it’s clear that the projects which have been pushed into the first half of the year won’t all happen as they were scheduled so what will happen?

1. Management by Emergency.
   This is almost certain. All the projects underway in the first half of the year are going to be under tremendous pressure. That pressure is sure to translate to emergency after emergency after emergency.
2. Low staff morale
   This is often characterized by high staff turnover though in the last 18 months or this has been less prevalent due to the economy. As a sidenote, one thing to be caustious about if you are in this situation is that the economy may be masking staff turnover even if staff morale is low. That may make for a big wave of staff changes as the economy improves.
3. Low productivity
   It’s simply not productive to have priorities change hour by hour or day by day. Staff are told “Do this. No, do that. No, do this other thing. No, do this again”. All the change in focus inevitably means loss of focus and less productivity.

Well if it’s that common, it should be easy to fix right?

Fixing this kind of problem is unfortuantley easier said than done. The source of this problem orginates a couple of levels higher that the PMO and can only be fixed there. Yet project managers have the methodology to fix this.

Now, you may have seen software tools that promote the kind of functionality that will “automatically” resolve resource overload challenges. Every project portfolio management (PPM) tool has something in this category. However, no matter what tool you choose, you will need to do the core work with management if you want to solve this dilemma.

Whether you choose software or not to help you fix this problem, here is what you’ll need to do from a process standpoint:

1. If you want to prioritize projects, forget about just giving them a ranking or some number, doing so just makes all the project sponsors crazy as they argue why their project should be a priority 75 instead of 92. Instead work with senior management so they agree on what business factors affect the importance of projects. Some examples might include:

•  
  • Return on Investment/Profit (an obvious one for private firms)
  • Project risk (again pretty obvious)
  • Technical competitivWheteness might be a little less obvious
  • Client satisfaction
  • Strategic advantage to the organization
  • Reduction or avoidance of threat to the organization

2. Create a set number of answers for each business factor. Try to stay away from a score of 1-5 or 1-100 and instead go for a descriptive answer. It will be much more powerful if you can have the answer correspond to a measurement. For example, “Improve Customer Satisfaction by 10% as measured by our quarterly customer satisfaction survey

3. Now you’ll need to create a formula that scores the answers from the business factors. This is where software may be attractive.

4. Finally you’ll need to weave in the cost of each project. You can think of cost in almost any denomination so long as all projects are measured the same way. So, total person-hours or person-days, total dollars or whatever. This will allow you to create a business factor score/cost calculation so you can determine which projects will give you the biggest bang for the buck.

Now, if you’re thinking you can do this in isolation and then present it ‘faite accompli’ to management, think again. Doing so will make you responsible for any project which is not priority #1 and that puts you no better off than you are already. The secret to success in this process is get senior management to define these factors themselves and to agree on the relative responses for each one. When that happens, the resulting levelled schedule is, by definition, doing the projects that are in the best interests of the organization first.

Project prioritization is often a part of project management that is avoided by senior management but the impact in a tough economy of avoiding prioritizing can be significant. That’s why looking at project priortization now may be timely. PMOs may find management more receptive than ever to participting in making this kind of process successful.

I was delighted to see the release recently of my friend Simon Moore’s book Strategic Project Portfolio Management and proud as can be to see my review of it on the jacket.  I’ve known Simon for years.  He’s one of the smartest people at Microsoft and he’s been in a unique position to see how organizations choose projects and, more interestingly to me, how they implement systems to help them choose projects.

It’s nice to see a book out of a Microsoft colleague that’s not just a how-to for Microsoft products.  Simon focuses on the process of choosing projects and how senior management has to take part in the process.

Take a peek.  The book is available from Amazon.  If you’d like to see some of the other things I’ve been reading, take a look at our Book Recommendations page.

It’s ongoingly amazing to me. I visit companies virtually every week that have projects that are suffering. The story about why these projects are not working is often the same, sometimes different but what is almost universal is that companies on a fairly regular basis get involved in projects that are out of their depth. When I ask these companies how they selected these projects, I’m often greeted with a blank stare.

The fundamental problem is that most organizations have no process for determining the appropriateness of taking on a project or not. The decision is much more complex than doing a resource levelled analysis of all combined projects but that also is often not done. There are several aspects to be considered here and I’d like to outline a few of them here.

Fundamentally your decision breaks down to a couple of main areas: Capacity, Benefit and Opportunity Cost.

Capacity refers to your ability to actually deliver a particular project and the answer to that may not be as simple as you might think. There are some obvious factors to consider of course. For example, do you have the resources and the skills required to deliver the project? Are those resources currently involved in other projects? Resources are more than just people although people, of course are key. It also includes office space, money, materials, access to the appropriate equipment and more.

Capacity also refers however, to something more fundamental. Do you, for example, have the organizational model to support certain types of projects? For example, your IT-type firm might have done dozens of successful $10,000 projects and have access to hundreds of other resources for a project that might be much larger. However, the odds are that you don’t have a business model established that would support a million dollar project regardless of how many other programmers you know. The simple infrastructure demands of a million dollar project are simply heavier and more complex to manage than most smaller-project firms are ready for.

Capacity might also include an ability to manage or mitigate risk. A firm that had always worked on low risk projects might not have the structure or financial or skill depth required to be able to effectively function in a high-risk project.

In the cases where your capacity is not up to where it needs to be to assure a successful project, it’s worthwhile to consider a joint-venture with an organization that does have that capacity or even passing on the project altogether.

The second area to consider is Benefit. It’s not enough to say that a project can be done. A responsible project manager should consider if it should be done. What will be the return on investment for this project to the organization? What benefits will the organization realize from the successful completion of this project and conversely, what are the potential side-effects to this organization of the project being unsuccessful?

Cost/Benefit analysis is often useful here and while you’re doing such an analysis it’s worthwhile to consider the different project risks you thought about while doing your thinking about capacity. What will be the benefits for example, if a particular area of scope or functionality, which you’ve identified as high risk, must be abandoned? Also, you’ve got to factor in time. Will the expected benefit be reduced if the project is late? Often in the commercial software development world, there is a window of opportunity that has been identified by marketing that, if missed, would severely reduce the value of the tool being developed. You should be weighing that against the risk of project delay while looking at capacity.

Finally, there is an opportunity cost to be considered. Opportunity cost is the value that would have been realized if you did something else with your resources. If you’ve been looking at your high-tech investments lately and wistfully thinking of the luscious earnings of a 4% government bond that you could have invested in, you know what I’m talking about.

In the project world, you’ve already looked at whether you have the capacity to do a project and what it’s potential benefit is, but you’ve also got to look at what else you could be doing with those resources that might deliver an even greater benefit. Perhaps, for example, an organization might realize much greater total value from the successful completion of 4 or 5 smaller and low-risk projects than from the successful completion of 1 very large but high-risk project. Or, perhaps the allocation of a small number of resources to a smaller but low-priority project will put a larger and more beneficial project at risk. We recently had to suspend work on a project that was due to complete in the next 3 months that we really, really wanted in order to ensure the on-time delivery of a much larger and much more important project. It was a tough call on a tough day but one that everyone agreed would deliver better overall value to the company. A good project manager must be able to point out to management the potential projects that could be successfully completed with the resources required for whatever you are doing.

Everything we’ve discussed here has a major assumption and that is that you have established a system for evaluating the feasibility of projects in the first place. It’s a phase, which perhaps seems obvious as we talk about it but in fact, is often absent. Perhaps some project managers feel they are not given the opportunity to not take on a project or perhaps the notion of refusing a project would be considered negative or career limiting to some. If you haven’t got an environment where a project can be considered before it must be adopted, it’s worth organizing one.

I believe the project selection phase is critical and, as an executive myself, I think that a project manager who returns to me to say that they’ve considered our project capacity, the potential benefits and opportunity cost of what we’re proposing and is concerned over what taking on this project will do to the company, rates high in my book.

I’ve been very encouraged in recent months at all the organizations that I’ve come into contact with that are making a real attempt at multi-project management.  It’s no surprise that enterprise-wide project management is a hot button right now.  The economy is tight and virtually everyone is trying to do more with less.  Also, the nature of business these days is that multiple projects are the norm rather than the exception.  With resources being commonly restricted (I mean no one has a complete spare project team just standing by in their offices, waiting for you to pick a project so they can start doing something), enterprise resource capacity planning has become the universal holy grail.

Despite these significant efforts in many major companies around the world, I’ve been asked more and more lately how to handle one of the most delicate aspects of multi-project management: prioritizing the projects.

In a lecture I gave recently I was speaking about the challenges of creating a centralized project management office only to be stopped cold by a comment from the floor.  “We’ve done all that,” said one CIO of a large Canadian company you’d recognize if I mentioned it.  “We’ve successfully created an enterprise project environment, loaded the data and now have produced enterprise resource-capacity planning reports for 3 months.  The challenge we have is that when we send the list of projects to management to prioritize, they all come back ‘Priority 1’”.

He’s not alone.  In working with companies from all over the world this year, I hear this comment has become all too frequently.  Is it surprising?  Not really.

There are several issues with this aspect of enterprise project management.  First of all, who wants to have the job of informing a senior manager that their project has now been designated as a lower priority?  Not me.  Not anyone, really.  So, as a consequence, when the issue comes up, there are few volunteers in the project team keen to tackle the challenge with management.  It’s easier in some ways just to keep going.

Next, there are plenty of disincentives for management to not elect their project to be anything but the highest priority.  Just like the challenge for project managers who contend for resources, the person who says their project is anything but the top priority is guaranteeing it will be delayed or even late.

When there’s a client involved, the conversation is even lest attractive.  Now, selecting a project for a drop in priority means contacting the client and dealing with a delay.  The impact may have legal implications and who wants to be bearer of that news?

Marketing will have a hand in things too in many organizations.  There is nothing with such high priority as your next client and a project for tomorrow’s client always seems more important to marketing than yesterday’s news.

When project managers go to management with their corporate-wide data and explain that there are only so many factors to manage and either the amount of work, the number of resources or the schedule has to give, the most common response is: “Well, we can’t hire staff – hiring freeze.  We can’t delay the schedules, everyone is counting on us to deliver on time and we can’t change the workload, those are our contracts.  You’ll just have to have your people work harder.”

For some managers, no presentation of empirical data seems to make any difference.  The consequence is that all projects are rated highest priority and everyone suffers.

Is there a solution?  Of course.  The secret to implementing culture change at this high a level of the organization is to be patient.  Starting with presenting some VP a list of projects and a red pencil isn’t going to be productive.  A better place to start is by outlining the problem to management without asking at first for a solution.  By highlighting the lack of project prioritization and the resources now being spent on what must be low-priority tasks, you may find a friendlier face for accepting an enterprise system in the first place.  Then, while working on the implementation of an enterprise system, start working on training exectuvies in the prioritization process.  Expect that in most cases, it won’t be complete in a couple of hours.

A skilled project manager will be able to paint a picture for management which first of all, shows that not making a priority decision is, in fact, a decision.  Also, the theoretical impact of project prioritization can be made to look very attractive.  Just about every project management software vendor has a demonstration which shows the impact of multi-project prioritization – it’s a key selling features for almost everyone.  This kind of demonstration can be part of your executive training and key to making the point that sooner or later, someone will have to deal with this decision.

Once you’ve got the ball rolling, implementing a new process without looking at real data is probably easier.  You’ll need to deal with ho to assess a project and some measures for setting a project priority which is just a subjective feeling.

Some key indicators for each project, which you might consider in your own process, are: the length of time project has already been underway; the amount of money spent on the project to date; the project performance in terms of cost and schedule variance; project return on investment to the organization once the project is complete; legal implications of delay; categorizing work into bill-for and internal; risk assessment of the ongoing project work and; the impact on other projects. 

Get the process documented and get the various managers to agree to it altogether.  It’s important to get agreement across the board because if one senior executive won’t play, then the incentive for everyone else to do the same will become astronomical.  There’s still going to have to some handholding when you get that first enterprise project list to deal with, but at least you’ll have paved the way.  If you can get buy-in for the basic process from senior management, you’re well on your way for that final stage in enterprise project management.  If not, you’ll still get benefits but the primary purpose of the system is likely to be thwarted.

It’s the latest, hottest topic in the project management workspace – “project portfolio management”.  At one time, what we meant by portfolio management was simply the management of multiple projects at one time.  The old term “multi-project” management referred to doing critical path and resource analysis and reporting of multiple projects grouped together.  Nowadays, the term often has an expanded meaning to include the authorization process of the projects themselves, a topic which is particularly interesting not only to me but also to executives everywhere.

When you think about all the statistics we’ve quoted in these very pages about projects that fail, I’ve long held that half the battle in improving these statistics is in affecting what projects were chosen in the first place.

If you’re a project manager, you might think that you have no influence over choosing projects; that they’re often handed to you with unworkable conditions as a fait accompli.  Nothing could be further from the truth.  Implementing a project approval process or “gated” approvals is the kernel of project portfolio management and it’s almost always initiated by the project office.  We don’t need to implement rocket science here.  Let’s start with the basics.

First, let’s establish an approval flow for new projects.  The first phase or “gate” could be the authorization to create a detailed plan.  This makes some sense as creating a detailed plan takes effort and/or money and expending effort is something that is almost always approved by someone.  The creation of a simple form whether on-line or on paper in which some basic criteria are established such as expected return on investment and alignment with business objectives. 

Once the detailed plan is created, it might have to be attached to a form with identified risks, bottom-up estimate of schedule, effort and costs. 

The combination would provide a baseline from which to measure if the project passes this approval.  Being approved through this second “gate might allow the project to begin execution.  Approval might include a calculation of return on investment based on the updated schedule and costs.

Regular reviews of the project status could be implemented in the same fashion, allowing the project to be ongoingly evaluated against a dynamic economy and changing business conditions as the project progresses.

A simple gated approval process can make a tremendous difference in a number of different ways.  First of all, just going through the process identifies risks and assumptions that might otherwise be ignored.  Management might have an assumption that a new product could be developed within a certain amount of time and for a certain amount of money.  The ground-up estimate might show that the product can’t make it to market in the time required to pay back the results expected.  Another common assumption is that key skilled personnel will be available when we need them but in the high-tech world there are often a very small number personnel that are so key that they can form a bottleneck to new project schedules.  Doing a skill assessment in our baseline and comparing it to existing projects will likely reveal the problem.

It’s no wonder that project portfolio management is such a hot button with management in this tighter, less forgiving economy.  The good news is that starting portfolio management by implementing a very simple approval process is possible with minimal effort in almost every organization.

Article: PPM and a whole new generation of acronyms
The extension of Enterprise Project Management concepts into the Project Portfolio Management paradigm means a whole slew of new definitions and their requisite acronyms.  How do the definitions within PPM match up with EPM and where do the concepts overlap?

Article: The human factor
A chief project officer isn’t just about numbers and analysis, they also have to consider how any change in the project management process will be received by those it affects.  This article describes a case study of a large retailer and how trying to implement Project Portfolio Management (PPM) was resisted by the very executives who had requested it.