January 15, 2010 / Articles / 2 Comments »

When Resources have to come from nowhere

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.

January 13, 2010 / Articles / Comments Off

Thanks to Scott Adams for a good laugh

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.

January 7, 2010 / Articles / Comments Off

Sometimes it’s better to look integrated than be integrated

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.

January 1, 2010 / Articles / Comments Off

Oh, what a year it’s been!

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.

December 23, 2009 / Articles, Deltek / 3 Comments »

Risk analysis software: A definite safe bet

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

December 16, 2009 / Articles, EPM Software / Comments Off

Managing Culture Shock

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.

December 11, 2009 / Articles / Comments Off

The Project Office; a time who’s come(again)?

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.

– – –

December 4, 2009 / Articles, Computing Canada / Comments Off

The Product Champion

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.

December 1, 2009 / Articles, Computing Canada / Comments Off

Put the right project view in the right hands

Given how project management software has taken advantage of today’s graphical age, there is a plethora of possible reports available for users of such systems. I’m always amused when we put such things as “200 reports included” or “thousands of reporting combinations available” in our marketing literature. Is this supposed to make people productive? As I work my way across the country and in different parts of th world meeting people who struggle with their own implementations of project control systems it’s easy to see why a system with hundreds of reports could be at once a great system to implement yet overwhelming for virtually all users.

When you start to distinguish the different kinds of audiences for these project management reports and the different kinds of reports available, the deployment of these systems makes a little more sense. Let’s start with the different types of audiences.

First of all, the users alone are an insufficient definition of the audience for the output of a project control system. These full-time or power users must be included, of course, but almost always, the users of a scheduling system are users at all because of the request or requirement of someone else. The users however will require detailed reports that allow them to identify work, debug input into the system, sequence and organize raw data into identifiable categories and orders and analyze the results of any analysis. In addition, this group will need to validate any other reporting into the system.

Another clearly distinct level of audience is the grass-roots input to the system. Some of these front-line personnel might use the system or use a “lite” level of access to the system but they will not typically be full users. The interest at this level for detailed analysis of the schedule will be low. Users at this level will be more interested in lists of tasks; in turn-around documents or forms to fill out while in the field and in simple schedules of what is expected of them next. How the system actually figured out what is expected next is of little use to them.

The ultimate ‘clients’ of many project control systems is another identifiable audience and that is the ‘Executive Suite’. Here the interest is not in the detailed analysis but in the synthesis or results of that analysis. Reports are expected in summary form with the all too elusive “One-Page Report” or an executive Dashboard being the ultimate goal for most executives. Trying to impress executives with a 20-foot flow chart of activities which stretches around 3 walls of the conference room will generally be unsuccessful.

There are likely several other potential audiences for project control reports. Project sponsors for example or the client themselves. Regulatory authorities often have specific requests and, if you’re in the defense business anywhere in the world, you’re likely to run afoul of Earned Value reporting standards. For each group of readers of the system’s reports you’ll need to look at their requirements separately.

Let’s turn our attention now to the kinds of reports which might be requested. Every project control system will have different types of standard reports but virtually every one of the systems on the market at virtually every skill level will include the following categories of views or reports: List reports sometimes referred to as spreadsheet reports, Barchart or Gantt views, Curves and Histograms, Activity Flowcharts, sometimes referred to as PERT, CPM or Network Logic diagrams, and Work Breakdown Structure (WBS) tree diagrams. There are a number of other more esoteric categories (scatter diagrams for risk data for example) and a variety of hybrids of different views but this is plenty for the moment. Let’s take these categories one at a time.

List or spreadsheet views are essentially text-oriented reports. These reports are organized in rows and columns just like a spreadsheet (hence the name) and these days are just as likely to look just like a spreadsheet when they’re output. Spreadsheet reports are useful for pretty much every audience depending on their content, their level of summary and the amount of data on them. A few products offer multiple lines of data per activity, most allow columns to be customized but only in one line per task. For executive reports, look for data to be summarized to a level of one line per project.

Barchart reports are sometimes referred to as Gantt reports. (After Henry Gantt who is credited with inventing them.) These reports are organized with tasks or summary tasks on the left with various columns of data and a bar or multiple bars against a date scale to the right. With abilities to modify what bars refer to what level of data, many different effects can be created here for different audiences. Typically, this is a good tool to use at the executive level if the system is capable of summarizing to one line per project and at the grass-roots level for individual schedules. Power users won’t often use a barchart except to validate that the schedule “looks” the way they’ve designed it.

Flow Charts are sometimes inaccurately referred to as Logic Diagrams or PERT charts after the charts designed for the PERT analysis method which is seldom used anymore. They show data at a detail level with one box per task and a line between tasks which are sequenced in order. In a good-sized project, this can add up to a lot of paper if you output the data. Still, this is the absolute best way to view the sequence of tasks. The flow chart is best targeted at serious users of project management software as the information contained in each box can be confusing for anyone not familiar with critical path methodology theory (that’s the name for the algorithm most often used to calculate schedule dates). In any serious project, there’s usually a “war room” allocated for the project team which should sport one of these diagrams as wall-paper. It’s a great tool to use while updating the project as you’ll immediately see the impact on other areas of the project when you change progress on a task. Also, having such a report ensures that proper project management techniques are being used and that the system is not simply a “barchart painter” regurgitating dates already specified by management.

Curves and Histograms show cost, resource and risk data. As summaries they are useful for management, in detail they’re of use only to experienced project managers. There’s likely no one at the grassroots level who wants to see the resource levelled histogram of data.

WBS diagrams are hierarchical tree diagrams just like an organigram. In a work breakdown structure however instead of an organization breakdown, you’re showing the breakdown of all work on the project. WBS diagrams are used to clarify other data and as such are best targeted at the power user.

In the end the system that you create should only have a dozen or so reports that are used with any frequency. These reports may be standard, out-of-the-box reports or may be customized using the many tools to be found in project control systems these days. Rather than looking for a system which has more reports than the next one, look for categories of reports. Does the system support the kind of WBS you’d like to see and are the customization tools there to alter it to exactly what you need. Finally, in this graphical age, see if the reporting view you like so much is also interactive. Can you display your data in this view then manipulate the data right on screen?

November 28, 2009 / Articles / Comments Off

Microsoft unveils Project 2010 Beta

Project Server 2010 Beta Yes, you too can get a preview of what’s coming in Microsoft Project 2010. Microsoft has released the beta for Microsoft Project Professional 2010 and Microsoft Project Server 2010. We’ve seen these products in the office for some time as HMS is a Microsoft Gold Certified Partner who has the Microsoft EPM Competency plus I worked on Microsoft’s EPM Partner Advisory Council for years and completed my participation on that council only recently.

But now you can start seeing what will be coming in the new product.

Among functionality that I think will be well received you’ll see:

In Project Professional:

Timeline View. This is like the Visio timeline bar that many people like for summary views
Team Planner. This interactive view lets team managers drag and drop tasks onto a team member’s schedule
The ribbon menu (also known as the fluid user interface)

In Project Server:

Integrated Portfolio and Project Server functionality. Yes, they’re together at last.
Project Data Pages. Not enough has been said about these but I think they may end up being the most powerful aspect of what people will now do with Project Server. The PDPs let you create forms to gather data and then use workflow to move data into different parts of the EPM system based on the context of the data at that stage of the workflow.

You can find the beta for Project Professional 2010 at: www.microsoft.com/project/2010/en/us/default.aspx.
The Project Server 2010 beta is at: www.microsoft.com/global/project/2010/en/us/RichMedia/secondary/server_home.html.

Category: Articles