Category: Articles

Home Articles ()

Article: “Agile” project management for a changing world


Here’s a number that I heard recently that, although it didn’t surprise me, is a shocking number to deal with.  It turns out that there are an estimated 40 million people on the planet who use Excel for project management.  As a percentage of the total number of people who must use PCs it’s probably not a huge number but as a percentage of the total number of dedicated project management applications sold, it makes Excel the most popular project management product on the market today.  You have to wonder what the attraction is.

When you look at project management packages in the market it becomes apparent quite quickly that they are feature-rich and require some level of expertise to take advantage of.  How many of us are using less than 25% of the functionality of our pm software?  Have pm software vendors missed the mark?  Are packages like Microsoft Project too complicated to be successful?

Not that long ago, pm software vendors used to think that the fundamental problem in the market was lack of training.  If only end-users were intelligent enough to understand what we could do for them, they’d surely implement an integrated high-end system.  Training, we all thought, was the best answer.  The market taught us differently.  It turned out that users didn’t want to be trained to use more complicated systems; they wanted systems that were easier.

The first wave of this has really reached its maturity level.  The domination of Microsoft Project as a desktop tool was largely successful because of how quickly end-users could produce their first results with the product. 

The next wave of pm software is underway.  Now, enterprise systems from numerous vendors are splitting the end user experience between a fully functional desktop tool and a much, much easier to use web-based interface.  It’s true that these systems involve more work to deploy but the end-results can be in an organization which must manage multiple projects with numerous resources  The newfound interest in the Project Management Maturity Model lends itself perfectly to these systems as the model is all about moving from ad-hoc project management to an integrated process.

But this leaves out the 40 million people using Excel.  There’s still a huge market for project managers who are most effective when working in an ad-hoc manner and have no desire to operate in an integrated view.  While meeting with Fujitsu Consulting last week, one of their managers coined the term “Agile” project management.  I very much like the concept.  There is no doubt a significant market for a project system that is even simpler than Microsoft Project Standard.  It would have to be low-cost, stunningly easy to use would have to be able to go from insert disk to useful output in a period measured in minutes, not weeks.  I know there are already products trying to target this market (Milestone comes to mind.) but these 40 million+ users are still not finding something that makes a sensible return on investment for them and I’m sure we’ll be seeing more attacks on this end of the market over the next year or two.

Now, lest someone worry that I’ve given up on my long-standing interest in enterprise project management, fear not.  But I’ve always believed that systems should serve a purpose and this category of ad-hoc project management is still not being adequately served.  Enterprise project management and moving to an integrated system only makes sense if it returns sufficient value on the investment of time and effort to deploy it.


Article: Maturity comes to Project Management

pm_maturity_4001It’s quite the buzz in the project management industry at the moment and it goes by the name of the “Project Management Maturity” model.  If you’re wondering if this is a relative to the IT world’s Capability Maturity Model (CMM), you need wonder no longer it’s a not-so-distant first cousin.


The idea of the PMM is that an organization’s capabilities of managing project management are assessed at a range of different levels.  There are several flavors of the model floating around but the most common iteration shows five different levels at the moment.  Labels vary but for the sake of conversation let’s number them like this: Level 1: Ad-hoc, Level 2: Planned, Level 3: Managed, Level 4, Integrated and Level 5: Sustained.  Ad-hoc is where you’d expect most organizations to be and you’d probably be right.  This means that project management occurs project-by-project in a non-standard manner.  Planned means that there is some standard for the planning aspect of project management at least but that tracking the project is done on a project-by-project  basis.  Managed would indicate that there is some normalization of how projects are both planned and tracked.  Integrated means that there is a method which brings the project management process and data together for all projects in the organization.  Sustained would mean that there is a reiterative process which would self-correct, self-improve and that the process would be self-sustaining.

I bring up the subject for two reasons.  First, there is a lot of activity in the industry at the moment doing PMM assessments, PMM implementation plans and PMM improvement projects.  So, if you’re not yet involved in such an initiative, you might expect to be soon.  The second reason is a little less obvious.  It seems that one automatically accepted aspect of this whole concept is that it is, of course, better to be higher on the scale.  I’ve been in meetings recently where this 5-level chart is put on the wall and a senior executive is informed that an assessment of the organization has determined that it is at, for example,  level 2.5.  You might just as well wave a red flag in front of a bull.  “Why aren’t we at level 5?!” the executive demands.  “I want to see a plan to get us to level 3 as soon as possible!”  Why?  Because 5 is obviously better than 1. 

It’s worthwhile to note that you can make a case for any one of these levels being appropriate for any particular organization.  We spend a lot of time talking to people about enterprise-wide project management in our firm but epm simply isn’t appropriate for some companies. 

You’ve always got to think of the overall return on investment.  In some organizations, the difficulty in implementing the culture change required to do epm outweighs the potential benefits.  In others, the shear diversity of the types of projects managed means that epm doesn’t return much investment at all.

For some of these organizations, being at a level 3, 2, or even 1 will be the most effective choice.

So, if you’re doing a PMM assessment at the moment, by all means, continue.  It’s always good to know where you stand and introspection almost always returns good value.  But, before you jump on the bandwagon to see how high up the PMM ladder you can get, make sure that the benefits are there.


Article: EPM stands for Effort Project Management


In 1994 I wrote an article outlining a disturbing trend in project management systems deployments.  At the time, there was a significant movement away from large-scale project management systems to PC-based systems.  The movement had really started in the mid-80’s with the rapid adoption of the PC as a work tool but the release of Windows had spurred the sale of project management systems as never before.  The original high-end project systems of the late 70’s, I wrote, cost in the hundreds of thousands of dollars and clients thought it quite reasonable to spend that much again on training and configuration.  The problem was, the systems of the 90’s cost only a few thousand dollars or less and the general reaction of clients I met was to spend an equivalent amount of money on training comparative to the value of the software rather than the training that had always been required.

I bring up the subject because of the recent advances into the enterprise project management domain of Microsoft.  There is a newfound interest it seems in bringing the enterprise together to manage projects and Microsoft is at the very forefront of that interest.  With the release two years ago of Project Server 2002 and the release of Project Server 2003 last year, Microsoft delivered a product that can be deployed as a enterprise project system.  What’s fascinating about the release of this product into the marketplace is the way people are going about using it to deploy Enterprise Project Management.

First of all, there’s no question that the concept is desirable.  Virtually everywhere I go from the smallest to the largest organization, there is a need to bring project information together and to strive for making better decisions about projects across the organization rather than project-by-project.

The legacy that Microsoft carries however isn’t helping it.  Microsoft has become known in the application business as a company that provides low cost project management software to the individual.  In virtually all of Microsoft’s applications, the expectation is that you’ll be able to quickly install the product yourself, configure it immediately and then be able to start producing results instantly.  The Windows versions of Microsoft Project all held to those principles.

Now, along comes Project Server and the ability to work across all projects at once and to group projects by portfolio and to collaborate with team members and PMO personnel alike.  Sounds like a match made in heaven, yes? 

Sorry, no.

The issue is the same as in 1994.  When considering the deployment of Project and Project Server, many clients bring their legacy of experience with Microsoft to the table.  In a recent conversation with a very high-tech firm, I helped scope out a deployment plan that called for about 4 weeks of configuration work including mapping processes to Project and then another 3-4 weeks of training for the 200+ personnel involved in projects who would have access to the tool.  Of the total, only about 2 days were involved with installation.  The project manager was stunned.  “I had figured on 3 to 4 hours,” he replied.  “with maybe a day or so more of training.” 

We’ve now seen numerous scenarios where an organization does a minimal epm effort and ends up having to go back and do it again, this time with less credibility with management.

The need for configuration and training shouldn’t be a big surprise.  When the same project managers are asked about any other major enterprise system such as ERP or CRM, they acknowledge the extensive effort that will be required to implement change.  Perhaps it’s the shoemaker’s children going barefoot syndrome where project managers can’t seem to apply the same logic to their own systems.

Maybe the solution to the problem is much simpler.  We should ask Microsoft just to add two zero’s to their project system pricing so we can take it more seriously.

Article: Be sure the cure is what you want


Years ago I had the occasion to attend a fascinating seminar about getting what you really want in life.  As an object lesson at one point, the leader offered to dissipate the headache of anyone who had a headache and who wished to get rid of it.  I won’t bore you with the procedure although I did see the demonstration done multiple times and with 100% success each and every time.  I was reminded recently of one of the key elements of the demonstrations which, I think, is pertinent to anyone doing an enterprise project management systems implementation.  Once a willing volunteer had been selected, the leader made a special point of asking them if they were willing to have their headache disappear.  This wasn’t a casual question, they said.  This was critical to the demonstration’s success.   The volunteer was asked to think about it for a moment to be sure they were willing to rid themselves of this headache.

I’ve been thinking lately that I should be doing the same thing with some of the larger organizations I consult about deploying enterprise project management.  Given our business, we’re almost always talking about the more technical aspects of such a deployment; installing epm and enterprise timesheet systems and configuring them to match a corporate epm process.  The problem seems to come up time and time again as we get near the end of the deployment and the system and/or process is about to go live.  Suddenly there is a burst of resistance from different sources and a pause as the epm project team considers what they’ve gotten themselves into.

It’s not like epm systems and epm processes don’t work.  They do.  There is plenty of evidence in case study after case study.  The problem is more that these projects are inevitably considered technology projects rather than change-management projects and, despite the advice of everyone involved, changing behaviour and culture is infinitely more difficult than installing software.

Moving an organization to work together in any aspect of its business is a challenge.  This is certainly so when we talk about project management.  The benefits to management of having data all gathered together seem obvious but the costs are not always apparent.  There is no question that deploying epm will always be a trade off. 

Ok, that sounds perhaps strange coming from someone who has been an evangelist for epm for 20 years or so but it’s true nonetheless.  Sharing resources makes for a great demonstration and, in a perfect world, seems like an obvious solution but there may be a penalty as project managers who have been able to successfully hoard resources by flying under the radar are now pushed to work at the same level of effectiveness as less efficient project managers. 

Having everyone see global data may seem excellent until you find that there are some who will use the opportunity of more data access to spend more time lobbying by using the data of other project managers than working on their own. 

Left unmanaged, it is certain that an epm system has the potential to make an organization less efficient rather than more.  John Chambers, the CEO of Cisco Corp. had a study commissioned where the effects of automation and the effects of process change were studied.  In some cases, the study found, automating then changing the process actually caused decreases in efficiency of up to 9%!  On the other hand, adopting a new process and then automating it caused increases in efficiency of up to 21%. 

The lesson is really one for me and people like me who work with organizations who want to implement enterprise project management.  When an organization says they’re ready to solve their problem, I’ve got to ask: “Are you sure you want the solution?”

Article: Project Management – Will you do what it takes?


2010 is an Olympic year in Canada.  Every time the Olympics come around, I must admit, I get emotional about those athletes who have given so much of their lives to participate in the greatest sports spectacle of our generation. I have a daughter who swam competitively and, as many parents do, I was struck with awe by the amount of effort she dedicated year after year to improving herself in her chosen sport. I’ve had the privilege of being at two Olympic Games. At my first, in Montreal in 1976, I worked at the games helping to raise the flags at different medal ceremonies. It meant hanging out a lot with people who had just won medals and had a profound effect on me. In 2000, I was able to take my wife and daughter to Sydney where we enjoyed the games as spectators. The perspective was very different. Perhaps having a teenager who goes to practice 7 times a week (2 mornings, 5 evenings) for 2 hours or more at a time, gave me a different look at the games but it struck me that the games aren’t so much about who wins. It’s true we obsess over medals but of the 10,000 athletes or so who are participating this year in Athens, only 500 or so will win medals. The other 9,500 have devoted years, in some cases more than a decade of their lives, to intense personal development and will have little or no hope of winning a medal.

When I bring this back to the project management industry and the organizations that I work with who are deploying enterprise project management systems and processes, the parallels are evident. Deploying epm isn’t trivial. Being successful in an epm deployment has a lot to do with treating the project seriously and being ready to do what it takes.

We have no trouble counseling a teen that to succeed in sport will take dedication and hard work but all too often we diminish the work required to make an epm deployment work.

Year after year we talk to mid and large organizations who wish to implement an enterprise project management system. It’s not just me, but many, many sources of information who outline what will be required to make epm work. Yet, somehow, time and again, someone in management characterizes epm as a technology project or as a simple software installation. The impact that changing how project management works might change the character of the entire organization is rarely identified. Yet many organizations in the past 20 years have become project driven. Project management has become a mainstay of management thinking and project management is definitely a horizontal industry.

Projects affect everything about an organization; where the money is spent, how effective the organization is at delivering new products, how fast revenue can be generated, how resources are allocated and much, much more. The idea that the installation of some new software will instantly transform this broad-reaching process from a silo-oriented single-user process into one where diverse employees and departments collaborate is optimistic at best and dangerous at worst.

We should take a page from those Olympic athletes who have planned and strategized and (let’s not forget) worked for a long period of time to achieve their goals. The question, you’ve got to ask is, ‘Are you ready to do what it takes?’


Article: Portfolio Management – Choosing the right projects


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: Making the CPO part of the Executive Suite

7463156I’ve been working with some project managers at McGill University in Montreal lately and was involved in a fascinating conversation that I thought I’d share this week.

The definition of a matrix organization is to structure the lines of authority in one aspect by resource grouping or department and in another aspect by project or objective.  Matrix organizations are not universal but are very common in today’s economy as they are ideally suited to organizations which manage multiple projects simultaneously which has become the rule rather than the exception.  In a matrix organization however, the challenge is to determine the actual accountability for results.

We typically charge the resource manager with the responsibility of managing the personnel.  They must ensure their department is fully engaged on productive work but they are also responsible for having their department trained and not to be too large or too small and to ensure that the staff are satisfied, that is to say not to stressed or overworked.

On the other side of the house we typically charge the project manager with producing results.  They must draw upon the skills available in the resource groups to do the project.  They petition the resource manager to staff their project with the best people available and then they must produce the result of the project with those people.

The matrix is often identified as a grid with a hierarchical tree going up and down like an Organigram and a 2nd hierarchical tree going from left to right intersecting the first tree with project responsibility.  The conflict between the interests of the project managers and the resource managers is by design.  In a perfect world, the natural conflict would be managed by a perfect balance between the two groups.

The challenge that I was faced with this week comes from two organizational phenomena that are rarely discussed. 

First, what happens when a person hold both roles as is often common in high tech.  Now you have a resource manager who has a heavy incentive to favor one project (their own) over the others.  How do you manage this conflict?

Secondly, the chain of authority from the resource manager up through the structure of the organization is often clear.  The team lead reports to the supervisor who reports to the department head who reports to the head of the division who reports to the VP etc.  The same is not true for almost any organization when we talk about the project managers.  What is their chain of authority?

I can diagram this easier than I can write about it so bear with me.  If I draw an organigram of an organization, where will the project management office reside?  Almost always, the answer is, as a dotted line next to one of the senior executives.  It is entirely possible that the project manager will hold no direct authority over another human being at all!  They are responsible, held accountable, but hold not authority.  This is the project manager’s most common lament.

In most organizations you also have to deal with the impact of different personalities.  Some people are simply better at getting their way or are more experienced or more skilled.  This can pull the matrix one way or the other.

A movement which is taking on more and more significance in the project management industry has had a direct impact on this area of the business.  The introduction in some organizations of a Chief Project Officer brings for the first time the strength of the project manager into the executive boardroom.  Now, the CPO can represent the potentially powerful project information from a project management office (PMO) at the highest level of the organization.  It’s a relatively new concept but one which holds the promise of a profound change in how organizations structure lines of accountability and chains of authority in making projects work. 

Article: Breaking down the epm business benefit


I was asked recently to help an organization prioritize its enterprise project management deployment. As we’ve often suggested here, the organization had done some homework. They had assembled a multi-departmental team to determine the aspects of epm that they considered important and they had worked over a series of months to articulate their process and to evaluate potential software vendors. They had determined that replacing an in-house timesheet system with a new timesheet system that would improve the time and billing process was their highest priority and had already purchased several hundred licenses of this time and expense system.

Sounds like there was nothing for me to do, doesn’t it? The organization had called me in because the scope of the deployment had recently undergone a significant increase and the head of the team was quite concerned that their entire plan was now at risk. The original scope had included several aspects of epm functionality including, of course, the timesheet but also a complete Enterprise Project Management system for resource capacity planning, schedule tracking and more. The selection of the timesheet system included, in part, the ability to link to Microsoft Project, which had already been targeted as the preferred epm system. The original plan was to deploy the timesheet first over a 4 month schedule then work on the epm deployment in the months following. Somewhere along the way, two things happened to dramatically alter the schedule. First, the timesheet vendor informed the client that a perceived deficiency in the abilities of the timesheet could be solved with the functionality of the epm system and second, almost simultaneously, management had renewed its requests for resource capacity planning information from Project.

The result was to move the implementation of the entire epm system forward and to implement the timesheet system and the epm system simultaneously. I was not particularly surprised to find that the schedule had not been lengthened at all as often happens during ‘scope creep’. The challenge I was asked to solve was to determine if the schedule was still viable and to look over the new scope of work to determine if this was the most effective course.

I mention all of this because the exercise we did together with this client is one that is done all too rarely in deployments of epm systems. We looked together at the final vision of the system from a business needs perspective. I asked the deployment team to identify business decisions they intended to make from the system rather than to identify a list of functions that they thought they would need. By focusing on the intended business uses of the system we were quickly able to list the expected business benefits.

The resulting list was highly relevant to their request. Over a couple of hours we were able to list the majority of the business benefits they were hoping for and the actual business decisions they expected to be better able to make once the system was deployed. Interestingly, virtually 100% of those benefits were focused around the functionality of the timesheet change rather than other epm oriented functionality.

This left us with the problematic functionality that had started the whole change in scope in the first place. ‘Who had reported the problem?’ I asked. The culprit was the chief accountant. An hour later we were meeting with him. Yes, he could confirm that this function was something he desired. However, when I asked how much effort was required to manually (ok, via Excel) manage this function now, the answer was ‘about 5 minutes or so per month’! Needless to say, with such a small improvement in efficiency as our expected benefit, the cost and effort of the whole epm deployment for this one function couldn’t be justified.

The lesson for all of us is to focus on the Return on Investment for each aspect of your epm deployment. What will be the intended business benefit and the intended business use of the system? Make sure you know how going through the exercise of deploying a whole enterprise project management environment will pay you back dividends.

Article: Getting over the first hurdle in EPM


The lesson was brought home to me in an unusual setting. I was speaking to a chemical expert who specializes in commercial swimming pool chemicals. He was explaining how the chlorine in the kills the bacteria which carry the bad bacteria. Until you reach the critical mass of chlorine, he explained, zero chlorides have been used and no bacteria destroyed. Once you hit the critical mass, all the targeted bacteria in the pool die and then you have to maintain the minimal critical level of chlorine to keep the pool safe.

What does this have to do with enterprise project management systems deployments you ask? Everything. Take a recent case in point that we’re working on right now. This is a CRM system deployment. The client has (not unusually) completely underestimated the total effort required to deploy the system. They’ve elected to put in a minimal budget with the thinking that their own personnel will be able to carry the project forward at a leisurely pace. The budget had very little room for experienced and expert assistance and was mostly focused on functionality training. Internal technical personnel were also budgeted for the smallest possible amount of time perhaps thinking that the internal personnel would be as efficient as a consultant who had done many of these implementations.

I’m sure you can see where this going. The budget for both external and internal technical expertise was quickly expended and, while the CRM system is installed and has some elements of the functionality working, there are large areas of the product which cannot yet be used because either they aren’t at all functional or they have not been configured with the necessary templates. Underlying architecture is also an issue. In one case the web server required both an upgrade and additional configuration and in another an incomplete installation of Microsoft Exchange had to be tackled. The end result is that the system does not yet have sufficient forward momentum to ensure it’s viability as a corporate system. What will happen here is that either the company will let the system limp along until something better comes along, or the system is abandoned or until it applies a bunch more resources and money to the project (perhaps even more than would have been required originally since they’ll be trying to rescue a project that’s already underway).

Sound familiar? I hope not. But this is exactly the scenario we often see in the enterprise project management space. The amount of effort required to validate the infrastructure, install the software and (most of all) configure the final system is underestimated about 90% of the time. A compounding issue is that the level of expertise and experience required is also almost always underestimated. The result is that systems do get installed but have elements that are not working and too little time to configure the system to deliver the results that were expected when the deployment was authorized.

There’s not a panacea for such deployments. Educating management, if possible, can reduce the heartache. If you are involved in an enterprise project management systems deployment, then determining the minimal working system may be a critical step in your planning. Aside from defining the complete deployment requirement which may be daunting to management, determine also, what effort would be required for a ‘viable’ deployment. One which, even if not all the functionality was deployed, would realize enough business benefit to be worthwhile. If you do, then the system will still be around to expand on later. If not, then you might end up with one more system to be rescued or replaced and all your efforts wasted.