“So, what were you trying to accomplish here?”

It’s a common question that I’ve had to ask of many project management office managers. Because of my background in enterprise project management systems, this mostly happens in response to some request to review a problem with a project management system implementation. Over the years I’ve been called upon to try to fix, repair, re-establish or just replace a failed or problematic project management system and my approach is always the same:

1. Tell me what’s going on?

It’s a good start and it gets the problems and the client’s frustrations up on the table right away. The story typically comes out in a jumble. (Think Pulp Fiction where the story starts in the middle and then jumps to the beginning, back to the middle, to the end and then finishes back somewhere in the middle.)

2. Distinguish the parts

I’m never presented with a single problem. Inevitably before the problem has been fully described, it’s more than one problem and it’s critical to distinguish out each of the moving parts. I’ve had lots of experience debugging system’s problems and anyone who has ever been in that role will tell you that it’s important to try to isolate the problems and then isolate the causes.

3. “So, what are you trying to accomplish here?”

Now that I have a fuller understanding of what is upsetting the client, it’s essential to know what they want to accomplish and therein lies the expectations of the client.

4. Design the solution(s)

The solution is often not obvious and determining the expectations often changes where to look for satisfaction.

Let’s take a look at each of these 4 steps in a bit more detail:

What’s going on?

When people describe a project management problem from a systems perspective the most typical description sounds like this: “It’s just broken”, “It just doesn’t work”, “It’s got a bug” or “The data is corrupt”. None of these of course are helpful. So we start by asking for specifics. “What did you see that makes it look like it’s broken?” , “Can you re-create the steps that make it look like it’s broken again?” , “Can you show me a report or a screen-shot that made you think it was broken?”

This sometimes slows the process down. Remember that the ‘What’s going on?’ process often arrives in a jumble and we may be looking at multiple problems. When the client can finally show me the report, field, screen or result that they believe to be a problem, the next obvious step is to ask, “What do you believe the result should be?” During this part of the analysis I’m often fascinated as how people produce results. I’ve seen people take information from a project management system, extract it to Access or Excel, manipulate it with macros, formulas and then extract it again, merge it with data from other systems and then point me to the end result and say “See? It’s wrong!”

Think that’s unusual? It’s not. Excel remains the most popular project management tool by far and project managers often have more experience in it than in whatever project scheduling too they’re using.

Distinguish the parts

When we get the offending result identified and I can determine that it is, in fact, not the result the client was expecting, it’s key to ask “What other results are not appearing as you expect?” Often there is one part of the data or the process that is the most problematic for today but there are other results that are only a minor irritant yet may have bear a significant impact on the problem. For example, I had a client who was unhappy with the resource levelling results of a project management tool. “Is there annnnyyyyyttttthhhiinnnnngggggg else?” I asked. Well, there was. There had been a minor irritation with how individual resource calendars were updated when vacations were taken. That opened up the door to how resource availability was defined and before you know it, we’ve got a fundamental break in the resource definition process as the main culprit. We standardized that process and how an individual resource’s availability was defined and presto – the scheduling results were all perfect.

So, what are we trying to accomplish here?

The answers to this question often amaze me and you’d think I couldn’t be so surprised after almost 30 years in the industry. The most likely easy answer is “We just want enterprise project management”. Of course I then have to ask what they mean by that. On many occasions lately what I hear is “We just really needed a timesheet”. The client has purchased an entire resource management, schedule management, portfolio management analysis system and then finds that the timesheet aspect of what they purchased just doesn’t give the results they were expecting.

It’s also common to find that the education of working on an enterprise project management system deployment has changed the perspective of what they really need. Perhaps they were enthralled by the sales demonstration before they got started. Perhaps they didn’t really understand what questions they should be asking. Perhaps more knowledgeable people were hired only after the deployment started. Either way, the notion of what’s now required evolves and by the time the client calls me to help get their project management environment back on track, the expectations of the original system are quite different from what they were before we started.

It’s also very common for the client to have gotten so caught up in the minutiae of system issues that they’ve lost track of what the original goals were.

This often brings us to a challenging aspect of the repair project. What if the new goals of the enterprise project management environment would be better served by not continuing to deploy the system they’ve already got a lot of investment in? We’ve had a couple of cases where the client was trying to deploy an entire enterprise project management system but in the end just wanted a timesheet. Do we keep banging the square peg in the round hole? Or, can we put that enterprise system aside for now and just deploy a more appropriate timesheet? Now, that’s a situation of going from a more complex system to one that’s less complex but I’ve seen the reverse as well. Someone takes a simple internal timesheet system and then tries to modify it with every enterprise project management feature they’ve envisaged. At some point it makes sense to pause that work and rethink the whole tool selection.

Build the solution(s)

I’ve been talking a lot about tools but often a solution can be found in the process. It’s common to find that some process that evolved over time or that is engrained in the corporate culture is the root cause of data analysis that makes no sense. Once we know what the client needs are, we can go back to the source and start with a solid process for collecting and analyzing the data. What the client originally thought of as a tool “bug” or “corrupt data” is often resolved with a change in how data is collected, in how it’s interpreted, with training or just by saying “don’t do that anymore” (I can’t tell you how many times I’ve had to say that).

It’s also possible that we can produce a result in a manner that the client hadn’t thought of. Once we know what the client is trying to accomplish, there are often a number of ways to get there that the client simply hadn’t thought of. From time to time, for example, I’ve had to say, “Why bother automating that? We can do it manually in 10 minutes per month with a lot less stress.”

If you take a methodical approach to solving issues that are a challenge to your enterprise project management environment, you’ll find that most of them are solveable very quickly. When it turns out to be expanding into a more and more complex problem it’s often good to take a big step back and look from a higher perspective. Figure out what you’re trying to accomplish, what benefit that will bring you and then how you’ve been trying to get there. When you break the problem down to its component parts and you can see clearly where you need to get to, building a path there is easier.

So, it’s time to bring it all together. You’ve used your talents thus far to choose the perfect project management software system; to implement it perfectly within your organization and to train your personnel within an inch of their lives. Now, it’s time to fulfill on some of those promises you made to management when they approved the budget in the first place and to integrate the project management system with other systems in the organization.

Here’s the first thing to know. Sometimes, it’s better to look integrated than to be integrated. Ok, that’s a little trite but it’s true. Over the years, I’ve met a remarkable number of otherwise clever people who use Ostrich management practices when thinking about integration. There are a couple of things to remember when talking about integration that can make or break your entire project management software implementation project.

First of all, regardless of what I say in the next few paragraphs, you’ve got to apply a reality check to every aspect of integrating multiple systems together. It is an easy thing to get caught up in the intricacies of a particular link between systems; to become enamored with how elegant the integration between two particular systems will be accomplished. However, if you don’t stop every once in awhile and ask yourself exactly how much effort this link will be saving.

Not long ago, I was consulting a firm who was designing an integration between a project scheduling system and the project invoicing elements of a central ERP accounting system. The person in charge was asked to describe to me how the link would be accomplished. For the next 30 minutes, in an inspired soliloquy, this person went on to enroll me in how completely; how elegantly and in what complex form the programmers would be able to create this automated link. It would take only 6 weeks of effort for a 4 man team to deliver this work of art I was informed.

That’s sounded great to me. After all, the presentation came with slides, flowcharts, ERWIN diagrams and a complete narrative. Clearly, this person had put their heart and soul into this particular aspect of the project. It was the cornerstone of his project management software implementation. I had only one question: How many transactions would his link process each month? That is, how many invoice items were there that had to be transferred from the project management system to the invoicing system? There was a long pause. An average of 12 was the final answer. And how long would this take to transfer manually? About 30 minutes each month, I was told. The 4 person/6 week effort would take over 36 years to pay dividends. I didn’t make this particular person very happy but clearly this particular bit of integration made no sense. This is, unfortunately, not an isolated incident. When you get so caught up in the details of a link between systems, it is easy to lose sight of the overall picture.

Here are a couple of basic elements to consider before embarking on the integration of your pm system with the rest of your organization’s automated infrastructure:

First, make a careful determination of what needs to be integrated. This may take some effort. First of all, you’ll need to determine what people want to be integrated. You’ll have to use your discretion here. Some people will be responsible for a particular system and have some notion that you will be integrating it poste haste. Their ideas of what will make the organization more effective or not may not be based on complete knowledge of what your project management system can do or has been configured to do. Just because someone (often very senior) wants two systems integrated doesn’t mean they can be, should be or need to be in order to make the organization more effective.

Next you’ll need to find out what perhaps should be integrated but that for some reason or another people are reluctant to have integrated. This may not be obvious. For a variety of reasons, there may be people who are responsible for a particular system who feel threatened by the integration of your system with theirs and who will therefore not offer up their system to be integrated. Some finance people for example, will feel that the movement of data into the finance systems from any external system risks compromising their system’s data regardless of the degree of integration. Yet, despite their reluctance, the linking of the project management system with theirs may offer huge potential benefits to the organization so you’ll need to seek such systems out.

Last, you’ll need to determine from the complete list of what can be integrated what should be integrated. Remember to apply a reality check on a regular basis to determine this list. You should constantly be asking yourself, “What is the return on investment of this particular link?” That is, “What is the estimated cost of this link in man hours or dollars and what is the estimated savings in time from doing the work manually?”

Once you’ve chosen the systems to integrate, you’ll probably want to start designing the links right away. This can sometimes be done with just the IT department but be careful. If you do not involve the people responsible for each of the systems affected during the very beginning of the design process you are risking a tremendous backlash.

People who are responsible for particular systems in an organization often treat them like they are their own children. Integrating in even the most non-intrusive, date-out-only fashion can make the feel violated. You must involve these people from the very beginning. Seek them out, ask their opinion about the integration. Find out what would make their lives easier and involve them in the design process. In far too many implementations, I have seen this not done only to find a link that is technically sound but practically unimplementable because no one has checked that organization’s process can support the link in the first place.

Remember, each link you are designing has the potential to invalidate the use of another. It may be possible, for example, to load budget dates from an accounting system or the shop floor manufacturing system. Yet, if you do both, how will you determine what is the source of these dates? You’ve got to look at the overall picture. Use flowcharting to follow data through the process you’ve implemented with your project management system to ensure that multiple elements of your integration plan don’t conflict with each other.

Also, before you start creating your first link between your pm system and the rest of the company, you have got to determine who will be responsible for it after it’s created. Beware. The operational responsibility of such a link may be very contentious. It may be perceived as something that gives someone power over another system. It may be perceived as very desirable or very undesirable and either can cause you problems. If you have involved the people responsible for each of the systems from the beginning, this question can be resolved with a minimum of fuss during the design process. If you haven’t you’re much more likely to end up with an emotional hot potato on your hands. So, make sure you design not only the technical elements of your link but the entire life cycle including maintenance, future growth potential, responsibility for usage of and control over the movement of this data.

Finally, don’t forget to apply simple rules of Return on Investment (ROI). It is the one sensibility check that will stand you in good stead as you create your design plan. The simple formula is to determine how much effort it will take to design, create, operate and maintain the particular link you are making and to subtract the cost of moving the data manually or using any existing structure. Working in person-hours is the most obvious measure but use any denomination for the analysis that works. Remember, sometimes it’s better to look integrated than be integrated.

“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.

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.

Selling software feature-by-feature used to be quite the rage.  ‘Feature wars’ were what software vendors engaged in all the time.  ‘He who had the most features won’ was the way we thought things worked.  The media didn’t help this much.  Reviews were organized by grid with a list of features down the side and a list of products at the top.  It seemed that it was the only way people could distinguish between products.

These days there’s lots of talk among vendors about the “solution-sell”.  If you’ve been involved in high-end software, you know exactly what I’m talking about.  The basic intent is for the salesperson to identify some problem; some ‘pain’ that they have the solution for.  Then the issue becomes showing how the software, configuration, consulting and training that is offered can help solve this problem. 

If you’re a client, you’ve seen this too.  You’d be on the other side, presumably articulating the problem you’re trying to solve and determining if what the vendor is proposing can actually fix the issue you’ve got. 

While this sounds quite an appropriate division of labour, delivering, one would hope, the best delivery of problem solving possible.  Unfortunately, the most common scenario I see when I’m in a software sales scenario is a conversation about features.  The entire request-for-proposal structure often devolves to this paradigm also.  Recently I was able to work with a couple of vendors on an RFP for a large high-tech firm.  It’s a bit unusual for me as I usually only see our own responses.  As per usual, the meat of the document was a grid of features, which the vendors were to fill out with a yes/no/maybe type of response.  As I worked with these vendors, it became clear that the responses from each of them were essentially the same.  From one interpretation or another the response for virtually every feature was a “yes” or “yes with some effort”.  What a problem this must be for the client.  All solutions are identical, yet each is clearly very different.  How can one determine from this the ideal solution?

Well, part of the problem is that most RFPs don’t identify a problem or, in any way, ask for a solution.  Most RFPs are just like the one I’ve just described.  They request a list of functions.   The premise is, that the group that has created the list of functions have already determined that this function list provide the solution.  The premise is fine but is often not always accurate. 

There are a number of reasons for this.  First of all, most software selections of enterprise systems are done by committee.  It’s a necessity, of course, since enterprise systems will affect so many people, many will want a say in their selection.  A committee with a diverse membership carries with it many influences and these all become apparent in a software selection.  Some of the influences that must be dealt with include: merging the primary problem with others that committee members and their groups are experiencing.  “Let’s get something that fixes all our problems.”,  the presence of existing legacy systems and the familiarity with features that exist in those systems “We’re still going to be able to see the code numbers on the left right?”, the desire by some members to promote their own solutions with products familiar to them “I’m sure we could do all of this with our integrated ERP system.”, and, last but not least, the desire by some members to use the opportunity of being on this committee to promote themselves (Now, I’m sure that’s not happening where you work.).

Trying to chair such a committee becomes all about keeping the group focused on its task.  All too often, however, the original task of solving a problem becomes a task of choosing a piece of software and the reason for choosing it can become lost.  Focusing on a feature grid and creating a structure for putting items on the grid or weighting them by importance must often be the path of least resistance for the people running such a selection committee.

We’ve seen the end result of this on a number of occasions.  The committee ultimately chooses software after a long protracted process and, while the installation is successful, the problem for which the committee was struck is still not resolved and the implementation, as a result, can never deliver the hoped-for result.

If you’re on the client-side of an enterprise system selection, you can make a difference by keeping the original problem in sight.  Run the selection committee like a mini-project.  Have a charter for the committee’s purpose and keep it visible in all your internal communications.  If you must create a feature list, make sure the guidance for evaluating it is against the original problem or problems that the given system is to fix.

You should be communicating the problem or situation you are trying to correct up front with the vendors you speak with.  Most enterprise system markets are made up of a small number of vendors.  The project management market in which I usually work is a group that is small enough that all the major players know each other quite well.  Once we find out what people are trying to solve with our software, we have often no-bid and suggested the 2 or 3 other vendors who are more appropriate. 

If you’re trying to find out if a given product will provide the solution you require, outline the elements of the problem.  Believe me, it’s all too rare to find these in RFP-type documents.  Ask the vendors to outline how they would solve this problem in the particular paradigm their product was designed for.  You might be surprised at the different quality of the responses you get. 

In the situation I spoke of at the beginning of this article, it was obvious from carefully reading the list of features that the context of the features was for a system that would be used for financial purposes and that data would be ultimately destined not only for project systems but also for financial systems such as payroll.  While that wasn’t mentioned anywhere else in the document, it was enough to have the largest vendor decide to partner with one or two of the smaller ones to provide the solution the client requested.  It was the right move.  Discussions with the client during the selection made it obvious that the large vendor had the features requested but that in practical terms, the solution desired could have never been crafted out of them alone.

So, don’t worry so much on the vendor’s solution-sell.  If you’re the client, make sure you’re concentrating on a solution-buy.

The Project Management Maturity (PMM) model is a pretty hot topic these days.  There are waves of consultants who can help organizations assess their “maturity level” which is pretty much always listed hierarchically with less mature being worse than more mature.  Proponents of the concept say the PMM model shows the capabilities of an organization to manage projects.  Whether you’re a fan of this assessment or not, there is another kind of maturity model that I’ve experienced personally and it has to do with the use and deployment of Project Management (EPM) systems

When we work with organizations who are deploying a project management system, it’s very common to find that the desires of the people doing the deploying is that they’ll get to enjoy every element of the new system they’ve just had demonstrated.  While there are a few showcase organizations that’ve been able to do this it’s much less common than you’d hope.

What is more likely is that there is a sequence of usage of such systems.

At the most basic level we tend to see Planning as the first wave.  Some organizations never get beyond this.  They make a basic schedule, bronze the GANTT chart then mount it on the wall of the project team’s office.  People refer to the plaque from time to time nostalgically as they remember the fine state of their schedule just before the project started.

While I’m being a bit cruel at those who are only using their expensive project management software to make a barchart, there is certainly value from doing so.  Creating an organized schedule tends to make the project participants think about how the work should be put together and is much more effective than doing nothing or just making a spreadsheet list.

Next in line in our experience is typically tracking.  An organization which is a little more “mature” in the use of their project management system will not only plan, they’ll track their schedules, advancing them on a regular basis with the progress to date and even look forward with projected schedules as the plans advance.  For many organizations, stopping here is effective.  They’re planning in their project management system then they’re working the plan by updating it regularly and even giving useful reports to management.

Once planning and tracking are handled, organizations tend to look to the resource management problem and how it might get resolved using their project management system.  Resources can have many aspects as I’ve discussed in here before but at the most basic level, resource allocation (assigning the work to resources) is a big step, followed by resource analysis of some kind. 

Cost management is the fourth typical area and many organizations never get here.  At a basic level, having a cost estimate broken down by phase or better yet by task in the project is a good costing start.  Tracking the actual costs either by hours or by dollars is the next level.

I’ll put a fifth area here for “Advanced” subjects and put Risk Analysis, Document management, automated workflows in here.  There are also advanced areas in each of the other four areas I’ve discussed so far.  If we were to diagram this the way that such things are most often diagrammed, we might end up with this:

This is the sequential kind of thinking and the problem I have with this is that it implies that level 1 is worse than level 2 and if only you could “get” to level 2 you’d have a better organization.  In fact, I think the diagram would be better represented like this:

In this kind of representation, at least we get away from the notion that each level higher is a better thing or that each block to the right is better than the block to the left.  In fact, even though I’ve described our experience that most organizations start to use their project management systems to do planning, it’s probably a good thing to imagine that they could start almost anywhere.  Some organizations could start working on resources perhaps or on risks or on document management. 

For each element I’ve described, we can also imagine more effort being put into that element to advance it further.  If we think about that for a moment, we might end up with a diagram looking something like this:

Now element that I’ve described has more depth of usage of the project system and perhaps can return more value from the system.  Planning for example, can be extended to include multi-project planning.  The algorithm for scheduling could be further extended into Critical Chain scheduling.  More detail could be added still and we could work with inter-related schedules with inter-project links.  The same goes for tracking.  If we extend beyond just percent complete, perhaps we now can look at tracking the resource usage along with the tasks.  Or perhaps we go from percent complete to remaining duration tracking which is more advanced.  From remaining duration tracking, we go to weighted milestones, something that’s often used in Earned Value calculations even when costs are not involved.

Each element can be extended further.  We could probably make a third level out from the center and then a fourth.

I think looking at the Project Management Systems Maturity model like this we can start from anywhere on the diagram.  Indeed, I’ve seen organizations not start their advanced use of their project management system in the planning area but rather in the cost area.  The organization does their planning from a cost perspective and before you know it, they’ve extended the costs section in tremendous detail yet haven’t done much with resources or risks. 

There’s no “right” way to advance in your use of your project management system or is there a “wrong” way.  As I’ve said in these columns before, what is most important is that you look first at what you need to accomplish in order to be more effective as an organization and from there design the solution to that challenge.

Use of your project management system is only one aspect of a possible solution and it’s up to you to decide how “mature” you should be and in what areas in order to make the management of your projects more effective.

I’ve been in a lot of corporate meetings lately discussing various aspects of delivering an “integrated” project management environment.  Don’t get me wrong, a corporate-wide integrated system is a wonderful thing to desire.  There’s no doubt that the idea of pushing a button on a screen and finding that every element of data across the company is tied to every other element in just such a way that the answers I desire are immediately available in every detail seems fabulous.

The delivery of such wonders, however, usually requires a little more thinking.  As you might imagine in the project management world, it is often a combination of tools that deliver the total functionality desired.  I know, I know.  Many ERP vendors have done a fine job not only in selling the idea that one tool delivers all solutions but in advancing their solutions to have their software actually do so.  The problem comes when deployment starts and in the field we discover a need for other tools to become a part of the “integrated” solution.  Often a scheduling tool such as Microsoft Project or Primavera will be part of the conversation; sometimes it’s a specialized tool for managing costs or risk or issue tracking. 

In every one of the cases I’ve come across in the past few months, all the vendors involved have been quick to point out how their tools are linked to whatever ERP or Finance system is in question.  Unfortunately it’s not always so easy.  Everyone is telling the truth of course.  The links being described or even demonstrated do work.  The issue is that they work in the demonstrations based on a range of assumptions that are not always made clear. 

It’s a truism that systems can only integrate at the lowest common denominator, but for some reason, that is not obvious to everyone who works on integration projects.  Recently, for example, I was asked to describe how the data from a high-level costing module of an ERP would move its data to the more detailed database of the scheduling tool.  The tools had been selected long ago and there was no problem with either.  During the deployment, the Finance group had worked on the configuration and deployment of the ERP system and the Project group had worked on their scheduling tool.  The decisions of each group on the configuration of the data were valid and justified.  The problem was, they weren’t coordinated.

For the desired system to work, the company would have had to managed data in the ERP at the same level that scheduling was doing.  This involved tens of thousands of tasks and hundreds of projects.  In theory, Finances system had the capacity.  In practice, it was unwilling to manage at that level of detail.  The result?  Data could be consolidated and rolled up from the project system but could not be “de-constructed” and moved down from Finance. 

For any integrated implementation it’s crucial to look at how systems and their data must be configured in order to integrate at a later date.  There are often trade-offs and compromises to make that are easier to do the earlier you make them.  Remember, just knowing that a link between systems exists makes systems integrateable.  It doesn’t mean yours are going to integrate unless you follow all the unspoken assumptions.

It’s a debate I hear often these days on a variety of enterprise implementation projects. Should the company invest in a commercial application or go the “open-source” route. I’m sure you’ve heard this talk before. A hundred thousand programmers are intent on giving away increasingly impressive software for free and making it available on the open market. The goal of this exercise seems focused around disturbing the future residuals of Bill Gates and people like him.

I took the opportunity recently to stop by sites like SourceForge to look at the various tools there, and I was quite impressed. There are tools in the ERP domain, collaboration domain and, my favorite, the project management domain. There are some major implementers now who are making a big play for this kind of software. “Go with our plan,” they say, “and don’t worry about paying another dime for software licenses. Don’t worry about software at all. Our team of implementers will custom-deliver a solution designed to fit your requirements exactly.”

It’s a compelling argument and seems attractive to companies facing a large license fee to purchase or upgrade to the next version of a commercial package. But, there’s a double-edged sword here that is all too familiar to those who have been in the industry for awhile.

There’s no doubt that free software has tremendous inherent value. Numerous programmers work on contributing to the project and many of these packages do work and do produce results that they intend. Also, in the last couple of years, if you were unfortunate enough to use systems of companies that didn’t survive the IT downturn, you may have thought it would have been better to own the product yourself.

However, when you make a decision to go with one of these systems, you are adopting responsibility for several aspects of the project yourself. First, you must be responsible for testing and quality assurance. Yes, I know, thousands of people test the product. Yet they’re each testing for their own needs. If you’re going to put something as critical as your corporate project data into such a system, you’ve got to test yourself. Next, you’re inherently adopting the entire future development path yourself. A commercial product moves forward based on the huge incentives of the market. It will adapt to new software environments and new business conditions over the course of time. This may happen with open source products – it may not.

The end result may be that you’re trading license cost for an ongoing cost of developers, testers and designers. You should make sure you really like the implementers who are proposing an open source solution as they may be around for quite some time. In the end, some organizations will find themselves spending a significant amount of time working on the design, development and completion of software which has become part of their infrastructure. That really only makes sense when your particular needs aren’t well served by software available in the market today.

It’s not new news. That’s pretty much the state the industry was in at the end of the 70’s. Custom software was the rage then. One of the reasons commercial software took off in the 80’s was that designing and developing custom software isn’t the core business for most companies. It’s still