Anyone who has worked with project management systems knows that the way you display data can dramatically affect the decions people make from it. This is why we often see GANTT charts with critical activities in red. I’m reminded of one of my very first sales of project scheduling software back in the 80’s. I don’t dare share the name of the organization but it was a large utility. We’d made this sale a few days earlier and now I got a call for “technical assistance”.

“I have a big problem. All my tasks are red,” the hapless client reported.

“Oh, that’s not a problem at all,” I replied. “Red tasks just mean that you are looking at the critical tasks. These tasks have been marked as red because they are on the critical path.”

“That’s another thing,” said my new client. “That word ‘critical’. That’s not going to work for us.”

There was a moment of silence. I was speechless. (For people who’ve met me you will know how unusual this is.)

“Perhaps the word ‘priority’ would be more appropriate,” I hesitantly replied. “Yes, that’s excellent!” said the client. “Now, what can you do about changing these colors? I need to get rid of these red tasks”

For those of you who have grown up with critical path methodology you might laugh. “This person needs training,” you might say. But I learned something very important from the interaction. My first reaction was to think that we needed to get in there right away and train people to distinguish between red tasks and blue tasks but I realized that the problem wasn’t his, it was mine. His perspective was that red tasks were a problem and that he’d have to take action to eliminate all the red from his report before he could give it to management. If you’re familiar with the critical path algorithm, this was going to be a problem because there are always tasks which are critical.

The challenge for the user wasn’t trivial. Even if I had trained him, he knew that his management would not appreciate the distinctions of critical vs. non-critical and would see red tasks the way a bull sees a red cape – they’d want to charge at them with as much force as they could muster.

When data moves beyond highly skilled users and into the hands of people who will only interact with it only occaisionally, choosing the display mode of the data is extremely important. In this day and age, the desire of management to get “real-time” dashboards and “live displays” of projects can lead to unhealthy project environments. Let’s consider the following very simple dashboard:

The situation here seems quite straightforward. Project 1 is running very late, Project 2 is slightly late and Project 3 is on time.

Showing this display instead of a complex barchart might be very appropriate to management. This display will draw attention to the schedule of Project 1. What should be done? Most managers would now query the project manager of Project 1 to ask why the project is late and what can be done to get it back on time.

That’s great so far. But next week when management sees the same report, is the same action appropriate? Probably not. Just having displayed the dashboard once has changed its context. If we display the identical dashboard with identical results next week, management will be likely to ask a very differerent question: “Have things improved since last week?” The display doesn’t show this.

So, we have the same data, the same author of the data, the same display, the same reader of the data but the reaction is quite different. This is because the context is very important. The manager of the project system has a couple of choices now. He or she can make a report that shows a year of icons for this display so the time factor can show management when the task becomes red and then goes back to the yellow caution and hopefully then to green. Or, they can try something like this:

Now both Project 1 and Project 2 are significantly behind schedule but we’ve added a new indicator to the graph. Now the trend of the scheduled delay is displayed. The eye naturally goes to the two red Projects: Project 1 and Project 2 and then to the right where we see that the trend for Project 1 seems to be improving and the trend for Project 2 seems to be getting worse. Also a concern is now Project 3 where the schedule is still on time but the trend is very much in the wrong direction. It looks like resources have been pulled from Projects 2 and 3 to work on Project 1 which is improving at the cost of the schedule of Project 3.

This is all still pretty good at the moment but you can see how the paradigm of such data expands exponentially. There is nothing quite so attractive to senior management than colored dashboard indicators and there’s a whole industry of people making indicators and formulas to drive them. In the simple example above, new indicators might be ordered up in a heartbeat. Was the improvement in Project 1 actually done at hte cost of Projects 2 and 3? What was the relative return on investment of working on Project 1 instead of 2 and 3. Perhaps this Red indicator caused us to move resources from our most important client to our least important internal project. How was the move of resources to respond to the red “X” in Project one aligned to our strategic goals? What did it cost?

Before you know it we’ll have a page full of symbols, curves, flashing lights and glowing buttons. There are a few other things missing from the whole display that are often overlooked. They can be summed up as timeliness and completeness.

Are we looking at all the data? Perhaps the project schedule is showing late but only half the tasks have been updated and when the data is all collected, the indicator will turn green. There’s no indicator in this simple display about how complete the data is or isn’t.

Is the data up to date? Perhaps Projects 2 and 3 were updated yesterday but Project 1 was only updated 90 days ago. Should they even be displayed on the same page? The data might no longer be relevant when compared from one project to another yet there is no indicator on the display that the data is all homogenous.

When we create display systems such as dashboards and summary reports we have to consider these things. I have a couple of basic rules about dashboards:

1. Less is moreJust because we can measure a thing doesn’t mean we should. Imagine a page with 500 colored indicators with 100 different shapes being used. That’s obviously visually stimulating but will it be useful? Almost certainly not. Yet, a page with one color on it (just red for example) isn’t useful either. That tells you to get into action but not where.

1. There must be actionEvery indicator should be able to have a related action to it. E.g. If the traffic light is red and the arrow beside it is red, then the VP must call the project manager immediately and review an action plan for getting back on track.

1. The indicator must have qualityWe have an expectation that project data that is reviewed by management has already been approved in some way. Yet management often asks for real-time dashboards that shows data long before it’s been reviewed or approved. Showing the quality of the data by either showing the level of approval, completeness or timeliness right on the dashboard or through some other process is key to being able to count on the decisions that will be made from the data.

1. The indicator is made for a particular audience.Making graphics dashboards with colored, animated flashy graphics is fun and, in this day and age of technology, not that hard. Designing such a display that makes an organization more effective is much tougher. So, every display we make is written with a particular audience in mind. Who will read this display and what is their context for the data.

The way you display data and what you display can make decisions and action possible that was impossible in the past. By the same token, a badly designed display can cause decision makers to make the incorrect decision inadvertently. So, think about what action such displays will cause as you’re designing them.

Whenever I am involved in the deployment of an enterprise-wide system I’m reminded of an analogy attributed to Buckminster Fuller (You remember Bucky. He’s the fellow who came up with the idea of geodesic domes.) Anyway, the story is about turning a ship. You see, when a ship is very large, say the size of a super-tanker, the size of the rudder to turn it must be correspondingly large. The problem is, that a ship such as this underway causes so much water pressure on the rudder, that the force required to push it against the water to turn the ship is incredibly large. So, someone very clever invented the “trim-tab” A trim-tab is a little rudder on the rudder and it seems that if you push that rudder in the opposite direction you want to go, the main rudder can be moved outwards with almost no effort at all.

Ok, cute story, but what does it have to do with project management software and enterprise systems? Well, everything.

The biggest issue with deploying an enterprise system is not the perfect selection of functions against requirements, it’s changing the corporate culture. For anyone working in a medium to large sized organization, you know that comparing the intractability of a corporate culture to the momentum of a supertanker is not at all inappropriate.

Over the past few years I have seen many, many fine individuals break their spirit over this issue. They know they’ve picked a product that will answer their firm’s needs but are unable to get it implemented throughout the organization. No matter how much force they mustered, it was never enough to ‘turn the ship’. The selected software ends up either completely abandoned or being used just by the core implementation team, another element to add to a fractured systems environment.

In those organizations where an enterprise project control system has been successfully implemented, inevitably, the corporate culture was changed a step at at time.

Operational procedures are business’s ‘trim tabs’ for corporate change. Now, lest you leap forward and think, ‘Great, tomorrow I’ll get started on a new procedures manual with hundreds of procedures to make people comply with our new corporate culture.’ or that you think you can mandate a corporate culture change by simply making a procedure called “change your cultural habits”, think again.

The changes that will be most effective will be insidious yet impactful. I was recently privileged to be in a conference session with a number of experts in the deployment of enterprise-wide project systems. A couple of their comments are worth noting. One of these experts described how their organization had designed a “knowledge base” of lessons learned on past projects. For some time the knowledge base had been established yet no one ever seemed to have the time to contribute to it. If there were lessons being learned, they weren’t being made available to future project managers.

The expert in this organization (you’d recognize this three-letter firm if I mentioned it), decided on a small change in procedure. Inside the contract for the project management consultants, a new line was added, identifying the contribution of lessons learned to the knowledge base as a deliverable part of every future contract. Hmmm, guess what? Suddenly every project management consultant seemed to find some new time. No contribution, no final payment for the contractor. This wasn’t a big corporate decision, Moses was not required to come down the mountain with stone tablets, it was a little one-line change to a contract template that turned the ship… a trim tab.

The other expert in this session had project managers who were not contractors, they were employees. Holding back payment in this scenario could not be one of the options. In this firm, a similar impact was made. On the project manager job performance review form, a new line was added. Project managers were now to be graded in their contribution to the project management process. Surprise, surprise, within a few months, project managers seemed suddenly interested in a process that they would have been hard pressed to identify in the past… trim tab.

What I like about both of these examples is that they started surreptitiously. All too often, when organizations attempt to implement a system company-wide, it starts in one of two ways. If the system originates from the mid-levels of the organization, then it rarely comes with the authority to deploy with every department and every user and often stalls within a close-held group. If the system originates from a high-level of the organization, then all-too often it comes with too heavy handed an approach. While upper management almost always has the authority to impose a structure, if it tries to impose a change in culture without considering the human impact, it runs the risk of creating “covert saboteurs”, staff who pay lip service to the new system yet make every effort in the background to stick to the old ways.

Culture change can be a sensitive thing. If imposed too quickly or too drastically, employees may feel threatened, their familiar world turned upside down. The most impactful changes are usually those which sneak into the system and the best way to deliver those changes is through small changes in procedures. Changes that at first glance don’t seem to change anything significant.

If you’re interested in change in your own organization, start looking for those trim tab opportunities. Ask yourself what change in function or practice would result in behaviour that would contribute to the deployment of our enterprise-wide system. Then, before implementing that change, ask yourself what the likely reaction would be to implementing that procedural change. If the reaction is likely to be major, you’ve not found a trim tab, you’re trying to push the rudder itself.

Of course, sometimes there’s simply no choice but to go with the brute strength approach. For example, organizations faced with a shortening calendar before the year 2000, find themselves implementing complete overhauls or replacements of core organizational systems. Where changes might have been better implemented over time, these firms must drive quickly, pushing the system in where it is required. If this is the scenario you’re facing, then other methods can mitigate the potential negative impact. Skilled ERP implementors use focus groups and familiarization sessions in part so that nervous recipients of the new system can express their concerns and have their issues answered by people with the control to deliver answers.

No matter what your situation, keep looking for those unique and powerful opportunities to enhance the situation in your own organization through the smallest of changes, the trim tab.

One of my favourite advertisements for project management software over the last couple of years shows a harried project manager with his head in a photocopier trying to clone himself in a desperate attempt to get more resources for his project. It’s a sentiment almost everyone in the IT community can sympathize with lately. If there is a CIO in the country ready to say “I’ve got more than enough resources,” I’ve yet to meet him.

The tradition method of increasing resource levels has always been to just hire more. Yet that option is becoming increasingly difficult for various reasons:

First, resources are often scarce. With IT project being ever more complex, programmers for varying development environments, systems analysts and others are sometimes hard to find. Recruiting and retaining key staff has become a full-time job for some managers.

Secondly, certain key skills are harder to come by than anything. One of the things that IT project managers come to know quickly is that the resource they absolutely need is the same person every other project manager in the organization needs.  The particular combination of knowledge, skills, knowledge of existing systems and experience makes certain technical people unique.

With the traditional method of resolving resource conflicts cut-off, many CIOs are looking to become more effective at managing what they have. Getting the most out of your resources is one of the promises of project management software and so it is no surprise a that the Project Management Institute is seeing more new members from the computer industry than any other.

So, what can you do to get the most out of your resources? Here are a few suggestions:

Find out what people are actually doing
This is no small thing. In many organizations, the amount of time “lost” in unallocated time is startling. For these organizations, there can be tremendous improvements in efficiency just in determining what people are spending their time on. An electronic timesheet system designed for project use finds a good target here. The system should be able to restrict the permissible charge codes to only those which have been created and authorized. This prevents countless hours from the dreaded “999 – miscellaneous” code. In one organization we’ve done some work for, implementing an electronic timesheet system “found” $60,000 worth of hours in the first month alone.

A corollary to this is to ensure that people are doing what they were scheduled to do. When we implement an enterprise-wide timekeeping system, managers are almost always amazed at what people are spending their time on. In some cases, staff members start working on tasks which were never part of they original project specification but that they think will be important.

Prioritize
Getting the right people to work on the right task is the next challenge. Project Management software which can identify tasks which should be completed before others and tasks which will have a greater impact on the total project (or projects) schedule allows a department manager to keep people focused. Applying an 80/20 rule to the problem says that 20% of the tasks will likely take 80% of the time. No problem if these are the most critical tasks on the project but in example after example, we come across projects which are running late where a significant proportion of the development team are mired in program cosmetics which were never part of the original specification (cute though they may be). A very clever coach once told me “work-ability before impeccability” telling me that while impeccable work was desired, just getting it working was ultimately more important. I’ve heeded the lesson since. When we do development now, we get the function working, before we add the spice, bells and whistles.

Resource Levelling
Some project management systems do a good job of providing resource levelling analysis. This analysis tells the manager where tasks will have to be scheduled in order to get the earliest possible date with the resources available. An advanced package will include the ability to show both a time-constrained analysis and a resource-constrained analysis at the same time. The time-constrained analysis assumes that additional resources could be made available but that the project schedule is inviolate. A report of this type of analysis will show the additional resources required in order to accomplish the schedule. The resource-constrained analysis assumes that no additional resources are available and that the schedule can be extended. A report of this type of analysis will show how long the schedule must be extended in order to complete the work with the staff available.

Neither of these analyses should be taken at face value. There are many techniques for advancing a schedule with limited resources including re-sequencing the tasks, changing durations, applying overtime and so on.

What is useful here is to find periods of peak resource requirement early enough to allow the manager to make preparations or to mitigate the problem. If there is enough notice, the manager can make a remarkable impact on the availability of resources for other tasks. Options for the project manager to consider include sub-contracting work, changing priorities of tasks, putting some low-priorities on hold or not starting some low-priority projects which might have otherwise taken up time. One of the things to consider is doing some work in advance in order to take advantage of some under-allocated time even if logically some of that work wouldn’t be done yet. For example, one wouldn’t typically start writing documentation until a piece of software was substantively complete. However, it might be possible to write quite a lot of system documentation and user documentation based on in-house standards and specifications. Even if some of the work had to be edited later, you would have gotten a huge jump on an area of a project which is typically a vulnerable point for project delays.

All of these techniques won’t create new staff in the morning but they have the potential to create tremendous efficiencies in resource management. Implementing any or all of these will almost always involve culture changes in your organization and, as I’ve said before in these pages, culture changes are not the easiest thing to implement. Take it one step at a time and make sure you involve the whole staff so that people know what the potential gains are for everyone if your operation becomes more efficient.

Of course, if that doesn’t work, the photocopier option is still available. It just seems, no matter how many times I stick my head in it, the copies that come out never seem to do as much work as I do.

I’ve been enjoying Scott Adams Dilbert comic strips for years.  They’re a treasure trove of laughs for people in the project management or timesheet software business as I am.  Adam’s Dilbert website has too many old strips to choose from so here’s just one that had me chuckle today.

Integrated project management environments are the envy of almost every executive in the country. In virtually every computer publication available there is talk about corporate environments being single source. Yet another TLA (Three-letter-acronym) has crept into our lexicon; ERP. It stands for Enterprise Resource Planning and generally describes large, centralized corporate systems which include not just the traditional financial systems but also production systems including project control. Companies like SAP, Baan and PeopleSoft have been promoting single-stop providers of project control environments. The year-2000 issue has prompted many companies to replace their corporate systems wholesale and this has further fueled interest in a centralized environment.

In the project-management industry the word “Integration” has been used so much as to become an oxymoron. Adjectives of varying degrees from “Totally” to “Seamless” to my all-time favourite “Watertight” describe systems which supposedly form different aspects of a complete solution for managing projects. In our company we’ve talked about the “Integrated Solution” so much it’s embarrassing.

But is it always productive to shoot for the “total” solution? There are several factors to consider. First of all, is the solution that looks so “integrated” in the brochures in fact as integrated as it promises? There are a number of vendors who have taken systems from different development teams or even acquired companies with products which were missing from their notion of an all-round solution and glued them together. Sometimes the most integrated thing about this combination of products will be the brochures themselves. It’s important to understand exactly what is meant by integrated different systems together even systems which seem similar in interface.

The acid test for integration used to be a proof-of-concept test where files from one system are readable by another but in practice this is not nearly enough. Data can never be considered in isolation. One of the more impressive examples of pre-sales testing I’ve seen by a firm recently has us doing our homework at the office. This firm has spent the last 90 days or so not looking at product features but rather generating data and scripts for testing. When they get to completing their tests between the 3 products they’re looking at later this month they will be looking at the data in as close to real terms as possible and they will be looking at the flow of data through the entire project control process. Seem like a lot of work? It is but the hidden bonus here is that when the system is implemented, there is already a very good system description of the control environment.

The second factor to deal with is understanding for yourself exactly what you require in terms of integration. We were asked recently for example if our TimeControl timesheet system would update the project scheduling system in real-time. It was this executive’s notion of the ultimate in integrated systems. As people completed tasks in the middle of the day, the project budget vs. actual would instantly adjust showing the advance of the project details. Sounds great but isn’t implementable. Aside from the problem of doing validation of the actual time and never knowing if all of the data has been collected (Ever had to find missing timesheets on a Monday morning?), the data would never be stable enough to be used for comparison against a budget. The issue here is that the data had never been considered as part of a process. For each organization, the requirements must be considered.

Finally, the benefits of being integrated inevitably trade-off against a higher degree of overhead for the total system. It doesn’t take long to see this. Imagine two systems, say a timesheet system integrating with a scheduling system. We’ve decided to tie these two systems together so that we can see budgeted costs vs actual costs. Sounds great but by integrating these two systems we’ve got to take on a couple of additional tasks. First, tasks in the scheduling system will have to be made available to the timekeeping system. Regardless of how “seamless” this process is, some degree of communication or coordination must be made between the keeper of the timekeeping system and the keeper of the scheduling system. Coding of the two systems must be coordinated. A process must be established for the movement of actual labour hours from the timesheet system to the scheduling system. A system of checks and balances must be established to ensure there is no data missing in the process. Another system of corrections must be established for inconsistencies between the two systems. Even in the most “integrated” environment, there is no escaping this establishment of proper process. Sound intimidating? It’s not really but it’s not trivial either. One of the most significant causes of failed integrated environment implementations is a misunderstanding of management of the process. Is it worth it?

So what are the options? Well, it’s worth considering at least having different categories of data to work separately. Look at the individual applications that you’re considering as part of your project control system. What benefits are available from each implementable aspect of the system when it is not integrated into the whole. If you can’t find any, you should be reconsidering why you’re implementing that feature in the first place. Examine how you could implement each aspect of the system distinctly and see if the benefit outweighs the payoff. If you are looking at products from a single vendor ask them to outline the benefits/costs of implementing systems separately. If you’re considering products from multiple vendors ask them each how they would make you more productive when these products are working in tandem and how they’d make you more productive if the products were implemented stand-alone.

Finally, don’t start anything without at least a rough implementation plan. Make sure all the players know when the system should be firing up and when the first benefits can be expected from different aspects of the system. You can always adjust a plan that wasn’t ideal but starting without a plan will ultimately cost you more than the purchases of the systems you’re considering.

We’ll look back on 2009 philosophically one day but there are many who are happy to see it come to an end.  When we started 2009 we had challenges in various sectors of the project management community.  But there were signs of things improving.  The US had just elected a new president; a man full of hope and promise.  The world’s auto industry was challenged but help would be on the way with a new administration. 

In the project management software world Microsoft had grown the project management software business yet again and its main competitor had recently been bought by its arch rival Oracle.  It promised to be a very interesting year.

Who would have predicted the depths of the financial industry crises or the incredible amounts of bail-out money that would be allocated to the private sector?

Project Managers all over the world have had to fight to keep their jobs this year, some of them unsuccessfully.  With less money comes fewer projects and with fewer projects we need fewer project managers.  Not every industry has been affected the same way.  Some project management consulting firms have had their best year ever.  If you do work with the public sector there was suddenly a big shift towards spending money in a hurry with all that bail out money needing good governance.  If you worked in the health sector, the H1N1 scare had all kinds of industries from vaccine distribution to hand sanitizer manufacturing scrambling to expand at breakneck speed.

The aquisition of Primavera by Oracle seemed to have little effect in the short term but my experience reminds me that effects of such mergers are usually slow in coming. 

2009 may have been hard for some in the industry but if you struggled this past year, take heart.  There is light at the end of the tunnel. 

2010 has some interesting changes for those in the project management industry:

Here at HMS we’re going to finally release our TimeControl 6 product.  There’ll be lots to say about this as we get 2010 underway but we’re very excited about this long standing project finally coming to market.

Next, Microsoft will release Project and Project Server 2010 “sometime in the spring” of 2010.  A major new release of project management software always seems to bring out changes.

The bailout money from various governments around the world that made such headlines in 2009 is only now starting to hit the streets and as it does a variety of industries will scramble to execute on projects that money and derivatives of that money make possible.  Even if you’re not on a direct bailout path, the recovery of a lot of the financial sector has made equity numbers improve and as a result, commercial credit is making a slow comeback.  As it does, more and more projects will become possible.

I predict one of the most interesting years for enterprise project management as a drive for efficiency takes center stage ahead of a drive for government compliance.

Happy New Year everyone.  Let’s make this a great one.

“What-if?” These are the two words most heard in the project management industry. Everyone on a project has his own “what-ifs”. Each member of a project team has his own perspective. But what everyone is referring to here is targeted at the same thought process. This is an aspect of contingency planning.

Good project managers, just like good managers of any kind, are constantly thinking of what might happen that isn’t currently planned for. For the most disruptive of conditions, they will likely have already mapped out an alternative strategy for dealing with the issue. This is fundamental to being a proactive manager. Lesser managers often find themselves managing by reaction or by emergency. This is a result of a contingency occurring for which there is no immediate solution.

Risk is often thought of in terms of insurance but it fits very well in a project management context. For those who are involved in schedule and cost management there are many tools now available on the market that can help.

There have been risk analysis project management tools available for your PC for over 10 years. Oracle’s Primavera has Pertmaster, a system which is designed to provide risk analysis and reporting for project schedules. @Risk and Risk+ are two products designed to provide similar analysis to Microsoft Project users. Deltek has WelcomRisk designed to add Monte Carlo risk analysis to its Open Plan product. This

So what does this software do? Does it tell me ho risky the project is? Does it somehow manage the risk for me?

First of all, risk analysis software does not do risk assessment. What it does is take the risk you assess to each task and provide analysis of the combined data to give you a view into areas of the project which might not otherwise grab your attention. What is this analysis? One of the most common algorithms is called Monte Carlo.

Okay, what’s Monte Carlo? Isn’t that where everyone goes to gamble? In fact, that’s exactly what it refers to. Here’s what happens in the Monte Carlo method: The user first inputs the minimum, maximum and best-guess of each task’s duration. In addition, the user inputs a type of curve. Examples of such curves might be a Bell curve or a Uniform curve.

The analysis is, in fact, just a critical path calculation. The difference is that it is done many, many times. And each time a task is considered, instead of just taking the original duration, the algorithm “rolls the dice” and uses a random duration. The randomness is controlled by the input. The algorithm uses the range between the optimistic and pessimistic durations and the curve to determine which duration to use. A Bell curve, for example, will tend more to the middle of the range where a Uniform curve will have an even chance anywhere along the range. The analysis continues through the project then returns and does it again. Often an analysis will perform 100 or even 1,000 passes through the project to deliver adequate results.

The algorithm returns information on each task as well as additional information on key tasks. So what’s the point? Well, consider a hypothetical project. In our project we have five tasks in sequence. Each task has four days of float or ‘slack’ time. Float is the amount of time an activity could be delayed without delaying the project itself. A task with no float is considered ‘critical’.

Okay, so we have our five tasks in a row. Imagine that the first task is three days late. Now the next task must have only one day of float. If it goes a day late, then the next three tasks in the sequence immediately become critical. A normal critical path methodology analysis, such as can be found in most project management systems, will never show you this information. However, a Monte Carlo simulation can find it easily. By rolling the dice, some of the time the first tasks will come up with a longer duration.

In combination with various reports, project managers can no be presented with two kinds of information. First, a listing of tasks which have a high degree of probability of becoming critical at some time in the project. Secondly, for key activities, a confidence curve can be generated showing a histogram.

There is another aspect to these reports which may be the most useful of all. This involves the trend of these analyses over time. Let’s consider this in basic terms.

On the last day of the project there is a 100 percent chance that the project will finish that day because, well, because it just finished. On the first day of a project, a risk analysis might tell that that the project is due to finish no earlier than Jan 1 and no later than July 1 of next year, a six-month range.

Each time the project is updated, the “risk” or the range should get narrower. Well what if it doesn’t? This can be a major indicator to a client or to the project manager that there is something severely amiss. It almost guarantees that there is a change in the project scope somewhere in your future.

Going through the extra effort of risk analysis isn’t often required on every project.  But, when you’re wondering what the impact is on a project with an unusually high number of risky assumptions, Risk Analysis software can go a long way to showing you some empirical results.

Over 90% of our new clients already own project control software. It’s a tough statistic to come to terms with generally and it implies a particular environment in which, in our firm, we live most of the time. If you’ve been involved with the implementation of project control systems in the past, you know that it is often the case that you are replacing a system rather than installing and implementing into an unsullied environment. The nature of the project management software industry is that it changes quickly and, unlike many systems, there is often huge returns on investment for getting the latest, fastest algorithm to calculate critically required project resources.

Dealing with the culture shock of a new system is bad enough but, as is the case with project control systems, that environment is “mission-critical” to the organization, the pressures of the entrenched culture can be fatal to the implementation.

Culture shock is inevitable in any major change of a system. It refers to the general upset that occurs when familiar systems are replaced with unfamiliar ones. Generally these systems are the oldest, most entrenched systems in the organization. Often, paradoxically, these systems are not even well liked and are complained about by the very people who will be most upset at them being removed. It is a testament to how much we crave the familiar to see what we will put up with rather than change. However, the phenomena can be a huge upset to personnel who are attempting to update systems and to make the organization more effective. If a successful implementation is essential to the success of the organization or the project, then this situation must be allowed for and dealt with.

Actions by those experiencing culture shock can be varied. Some users, faced with a new system will resist actively, stating their objections and demanding satisfaction. These are the easiest to deal with as the dialog to resolve their concerns has already been started by them. Other users will simply not use the new system, sticking with the old system if it is still available or not using anything at all and not speaking out about it. Perhaps the difficult type of reaction are the “covert resisters”. These people will pay lip service to the success of the implementation, declaring themselves to support it yet, their every action will do the opposite. In particular, the longest standing staff members are most susceptible to this shock reaction and are most likely to have close contacts in upper management where a few well-placed words can wreak havoc on the implementation plan.

The effects of this culture shock can be significant. Users of the new system may experience a long period of confusion with the new system, insisting in vain that it work like the “old system” even if the old system was flawed and inaccurate. This confusion can rapidly lead to general ineffectiveness across the organization.

Recently we were involved in an organization-wide implementation of a new project control system on a significant project. As anyone who is working on large projects knows, the pressure on the project team, indeed on the whole organization is intense. In this case, the project management group had determined that the cost of staying with an outdated project control system outweighed the disruption of replacing a system which was used across the enterprise.

With time being of the essence, training, consulting, data-conversion and system configuration were all on the “fast-track” with many tasks working in parallel to get them up to speed in the minimum time possible. However, with the core project management team focused and working overtime to get the system up and ready, they were less available for the human element, spending time with the remote office users or working on focus groups and sitting in on training sessions. The result? Not surprisingly, the initial “go-live” week wasn’t as successful as we’d hoped. The system was rolled out, worked with little technical difficulties for about four days. However, the reaction from almost every corner is that the system “doesn’t work the same way as the old system”. So may users reported that they couldn’t deliver key project data in a timely fashion that after the first four days, the project management team relented and instructed users to return temporarily to the old familiar system for several days while these “issues” were resolved. An intense retraining and internal marketing campaign restating the returns that the end user could expect along with some key support from upper management at just the right time made a second run at the implementation much more successful about 2 weeks later.

This implementation was successful but over the years, I’ve seen many that are not. The culture shock reaction from the end users is so unexpected and, so intense, that the implementation dies on the starting blocks and never recovers.

So what should you do to avoid this scenario in your own implementations?

First of all, expect it to happen. The most vulnerable implementations are those where the implementors naively assume that the new system will be welcomed with open arms by all involved.

One of the most significant elements that should be part of any enterprise-wide implementation is upper management support. Find a champion for the implementation who won’t shy away at the first grumblings and make sure that someone has enough authority in the organization to make sure the implementation will not be abandoned. Also, (do I need to say this?) make sure that person is apprised of the potential for culture shock and prepares for it.

Next, plan on a significant effort communicating with and informing as widespread a range of users as possible. Run focus groups, or information seminars, or just get a newsletter going. Make sure there is some mechanism for feedback by the end users. Nothing ticks people off more than not being able to be heard.

Three words: Training, Training and Training. Can I say this enough? Spend more time training than you’ve already planned. Planned a lot of training? Put some more into the plan. Even if the training sessions become more of a user-group meeting or bull-session, all the better. The more users are able to get out of the new system, the more likely they’ll be to support it.

If it’s possible, a phased approach will often help in this kind of implementation. Start with the group most likely to succeed, not the group making the loudest noise about what’s not working.

Finally, keep selling this solution. Many groups will do a selling job for the new system one time early on in the plan then not return to it again until the software is actually installed. You’ve got to keep selling the new solution until it becomes the new culture.

In the dawn days of project management software, there was no such thing as “Desktop” systems. Indeed, there was no such thing as a desktop. The use of early project management systems were done entirely in mainframe or very centralized environments and by personnel who were very specialized as well. Given the extreme cost of setting up such systems, it was only on the very largest of projects or most complicated of project environments where they were found.

Consequently, the most common, almost universally accepted organization for the use of these systems was the ‘Project Office’. In this office, one would find a small cadre of skilled schedulers estimators and project-related experts who acted as a broker of information. They were identified on many organigrams as outside the normal hierarchy of business through a dashed line connecting somewhere high up the corporate ladder; a sort of ‘black box’ from which important information flowed.

The perspective of management is that this office were the eyes and ears of management, reporting on the status of the project. From the field, these people were known as the schedule ‘reporters’, reporting on the efforts of the people actually doing the work.

The truth was usually neither of these. The project team usually walked a fine line, delivering the results of their analysis in the formats that would most benefit the project to the people who most needed the information. They were often the only people who had perspective on the project as they were the only people who, from week to week would “walk the project”, taking notes on the progress of each piece of work. They were able take advantage of that perspective by specializing in the analysis of the project, looking day-by-day at project schedules, alternative strategies and the pace of work. The first software systems that these offices used were large, unwieldy and user-hostile. It took imagination and no small amount of effort to produce the results required out of them.

The analysis that the Project Office delivered was important but underlying it all was something that was at least as important and not immediately obvious until the nature of computing changed.

The advent of desktop computing brought with it almost immediately desktop project management software. The software category was ideally suited for the latest in computing and the notion of more friendly and more flexible software for scheduling was quickly adopted by both experienced and novice project managers.

In the early heady days of PCs no one thought anything of the distribution of project scheduling work. The notion of the project office seemed passé. After all, the software no longer required a dedicated skilled operator. Some new desktop planning systems could be used within minutes and mastered within hours and produce reports that looked every bit as good and as professional as the old system. It is more the exception than the rule now to find a project office. Mega projects still have them, older organizations who have had project management as part of their culture for many years still do as well; consulting engineering firms for example. Yet the need for such systems is no longer as obvious.

Users have flocked to desktop systems in droves but along the way they’ve lost out on something that was part of the underpinning of the Project Office, part of its fabric. It’s true that the product of the Project Office was schedule reports but it’s equally true that to do so required the Office had to create project management practices and procedures, standards, naming conventions and more. Desktop systems have successfully replaced the user functionality with systems that are faster, require less hardware and are so user friendly that they no longer require skilled operators but what has been lost along the way are the benefits of the effort put into organizational practices and procedures for the management of that data.

These practices and procedures included things like naming conventions. For example, in such an office it would be unthinkable to have different project files using the same code for different resources. There would be a consistent and identifiable time for project status updates in order to be able to compare different aspects of the active projects against each other. Reports would be standardized in order to enable the grouping of multiple project files together. Even if such reports weren’t standardized, the people who created them for one project would be immediately available to create them for others. Common codes such as Work Breakdown Structures might be shared among all project files in order to make them comparable later.

The absence of the Project Office has now become more and more apparent as the pendulum swings back somewhat in organizations that are now attempting to coordinate their project management efforts to produce enterprise-wide analysis and reports on projects anticipated or in progress. Enterprise Project Management Systems are lovely marketing terms but without the structural underpinning, they are simply a lot of features with the potential for delivering organizational project management.

Is it time for the Project Office to make a comeback? I think so. It would not, however, be the Project Office of old. With the advance of project management systems today, there’s not much profit in re-centralizing the user functionality. What is sorely missed however in almost any organization which is trying to implement a cross-department or organization-wide project control environment are the standards that must exist for such a system to work.

A new breed of Project Office may be the only way to ensure enterprise-wide project management. The mission of such an office would be to establish standards for all users. The new Project Office would be the publisher of naming conventions, of common coding structures, of report formats, of common calendars and shared resource files, of data standards that will make merging data later even possible. Their task is not made particularly easier by easier-to-use software. With individual users able to operate independently, it becomes more difficult to impose these kind of standards.

The new Project Office is also an ideal place to centralize project management expertise and to establish whatever project management training might be required for the organization. As a source of training and useful data, standards can be ‘snuck in’, offered as a path of least resistance (my favourite concept in implementing project management across the enterprise). The Project Office loses its “Big Brother” stigma and becomes a sort of super help desk, delivering as part of its own fabric the practices and procedures that make enterprise project management possible.

- – -

If you’re implementing a project control system, or any enterprise-wide system, one of the most significant elements to consider is the product champion. Without a knight (of either gender) to champion the cause, the chances for a successful implementation drop dramatically.

So what is a product champion? It’s a person who is held to account for the success of the system implementation. It’s a person who on a given day stood up and said, “You can count on me. I’ll make sure that this system works for us.” A champion, just like a Knight of the Round Table has to be backed by the king. Without any authority from management, few people would (and no one really should) take on being accountable for a system implementation project.

There are several key elements to implementing any enterprise-wide core system which could handicapped or even block a successful implementation. We see this almost every day in deploying our enterprise timekeeping system or project management software.

These elements include:

Lack of Planning
Can I say this enough? Make sure you manage the implementation of your project management system with a project plan! We estimate that 4 out of every 5 implementations are attempted with little or no planning whatsoever. Without a project plan, the chances of being successful are slim. Without clearly defined goals, a well thought out budget, a manager who is committed to achieve those goals and management support for making the plan work, there’s little hope of getting anywhere. One of my favourite Chinese proverbs says “If you don’t know where you’re going, any path will take you there.” If there’s no clearly identified goal that everyone is committed to then how could you achieve it?

Duration of the Plan
There is an illusion that a project management software implementation (and many other enterprise systems) are complete as soon as the software is purchased. For anyone who has been involved in deploying such a system you know that purchasing the software is usually just the start of the most difficult aspect of the implementation process. If there are unrealistic expectations that the project will only last a few weeks, or a couple of months, then as the implementation drags into its sixth or seventh month, it may lose critical support. An enterprise-wide implementation for a mid-sized company can easily last a year. ERP implementations are often targeted at 2-3 years. This can test the most patient of supporters. Without the champion keeping the project alive, keeping people enrolled in the project and keeping the group enthusiastic about the end result, focus will ultimately be lost.

Lack of long-term support
Many things can affect long-term support for an implementation project. Management changes where responsibility shifts from one manager to another can be a key factor. Staff changes which change the composition of a selection committee or removes a key resource can have a dramatic impact. Before the process even starts, it should be made clear that the people signing on are signing on for the duration and are made aware of how long that support will need to last. A Product Champion may be the only continuity in a project which sees many changes around them. It is their responsibility to keep the project on track.

Lack of Focus
When you’re starting your system-wide implementation project, everything will seem very simple. After all, the core team who are starting the process will be comparatively simple to bring to a consensus on varying issues. Once the deployment of the system starts however, life will take a dramatic turn. Suddenly every personal, individual, conflicting interest in the organization surfaces as “must-do” requirements. Interests which for a variety of reasons will be defended to the utmost by the people who support them. It is here that focus will become the most important aspect of the implementation. Without a central figure to reaffirm the project’s goals, these divergent interests can drag the project right off the rails.

Power sharing
While I’m sure this is not an issue in your own organization, I must confess I’ve seen this occur in some organizations across the country. As it becomes apparent to people throughout the organization that the enterprise-wide system will actually impact them, some people will perceive this as a threat to whatever “power-base” they’ve created by using their own personalized systems. These people may have a great resistance to fully participating in the new system. Those who are very public about their concerns are the easiest to deal with. The most difficult (and I’m confident that most of you have never experienced this) are those who publicly proclaim their support of the system while in the background do just the opposite. The only way of overcoming this phenomenon is to have a central person who enrols or re-enrols these people in the vision for the whole organization, in the benefits for everyone that will come from cooperating. Someone who has the knowledge and authority to resolve their concerns. The person most invested in making this work is always the product champion. This particular subject is dealt with in much more detail by Peter Senge in his book “The Fifth Discipline”.

All of this points to a single solution; an individual who will hold the goals of the project against any and all resistance; someone who believes in the project and who knows they will deliver; someone who has both the desire and the support to make the project successful.

“Oh wait,” you say, “we’ve got just the thing. Our implementation committee are absolutely committed to the project and include all kinds of skills. Surely this is even better than your ‘product champion’”.

Sorry. Not so. A committee is one of those entities with many legs and no intelligence. It almost always results in management by consensus or worse. The keyword here is accountability. You can’t hold a group to account. You can make them responsible but there’s no way to hold them to account like you can with an individual. If you’re an executive sitting with your implementation committee and wondering if the project has any chance of making it your request should be this, “Would the person who is ready to personally promise me that this implementation project will be successful please stand up.” That’s your product champion. Don’t get started without them.