Category: Articles

Home Articles ()

Deploying a Project Management System

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

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

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

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

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

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

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

Work on some of these questions:

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

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

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

Deploying Project Management Software – The Plan

In our last issue I talked about determining your requirements for a corporate project management system. This month we’ll talk about creating your plan for the deployment of your project management system.

What?! You don’t have a plan? Well, there’s good news and bad news. The good news is, you’re not alone, many project managers have attempted to deploy their project management system without a plan. The bad news? You’re not alone, many project managers attempt to deploy a project management system without a plan! I think it’s the ‘shoemaker whose children are barefoot’ syndrome. We tend to apply our skills last to our own projects.

The first step in making for a successful deployment of your project management system is in looking at the exercise as a project with everything that entails. Does this project have a sponsor? Who is the client? What is the schedule? What are the conditions for success? Here are a few elements you should be looking at when you are planning out the deployment of your new project management system:

Management Support
First of all, does this plan have management support. Problems with deploying project management software suffer most often from a lack of a product champion in the executive suite. Sometimes, decisions about implementing pm software come from management as a reaction to some problem (either real or perceived) about a particular project or projects in general. This might look like executive support but the support is very short term. Does management understand the scope and duration of the plan or are they hoping for an overnight fix? (You know what I mean – “As soon as that new software’s here, all our projects will be back on schedule”)

Look for management support that will last long term – It may be a year or two before the final effects of this implementation are felt. Is your project champion ready for the usual backlash that comes with a change in culture?

Also, what about funding. In this day of $300 project management software it’s easy to overlook the overall costs of implementing a change in a corporate system. Will you have the funding required for training? How about consultants to help tie your pm system to other legacy systems in the company? Has the I/T department set aside funds for technical support or people to help with the implementation?

Getting a product champion identified at the highest levels can be the most significant factor in overcoming the problem with all projects: Murphy’s Law.

Degree of deployment
While you’re assembling your plan, one of the most significant elements will be its scope. Implementation of a project management system if often thought of in one of only two camps: 1) Let every project manager do what they want or; 2) Choose a corporate-wide system and implement it everywhere. The problem of course with either plan is that few organizations benefit from them. The most common structure is one where some projects warrant a high-end project scheduling system, other projects warrant some kind of desktop planning system and yet other projects are so simple they warrant no project scheduling system at all. While you’re deciding who will and won’t be using your newfound package, think about what the payback will be for project managers at different levels. It is sometimes easier to leave small, low-risk projects out of the plan altogether. They’re numerous, they’re often very unique, very different from each other and the payback of having them in the central system is often very low.

Deciding on your level of penetration in the organization will be critical element of success. Pick your battles. If the small-project project managers want to do their own thing, it may be worth your while to get them off your list by letting them.

PM Process
Have you thought of where you’re going to gather the data for this new and improved software? Is the company ready to provide it or are you looking at cultural changes in the way they operate. One of our clients recently was working on implementing the corporate timekeeping system we publish. Management committed the company to move to a weekly time collection from the bi-monthly payroll-oriented collection they used to use in order to properly implement activity-based-costing. “No problem,” said management. Well, it has taken an enormous effort to get that message out to the rank and file who were so used to doing the work on the 1st and the 15th. Some resist doing the timesheet weekly despite the obvious advantages for the company. You need to look at what your new system requires and plan for it in advance.

Implementing a new package is also a perfect time for implementing process changes that may have been long-delayed. People will be changing anyway. You might as well take advantage to have them change to more productive ways of working.

Training
Can I say this enough: training, training, training. Not just in product functionality. Make sure you put aside enough funding and time to get people trained in the new way they’ll need to do business in order to support your new system. Make sure people know long in advance how much time will be required for users to come up to speed and make both an incentive to get trained and a penalty for avoiding it. It doesn’t matter if you spend $300, $30,000 or $3,000,000 on your new system; either get your people trained or plan to use the new CD for a coffee coaster.

Legacy Data
It’s a category that too many people forget. Unless you’re a start-up, you’ve got projects in progress. What will you do with all the legacy data from you existing system? That system may have been automated, may have been database-based, it may have been manual. You’ve still got to consider the value of the data in that system (or systems) and arrange the resources required to get it translated into the new system. Data conversions are often a tricky business. Get your new software supplier to check on the data and give a firm-price bid on converting it. You may need to pay them a day or two of investigative time but the back-end savings will make it well worth it.

Legacy Systems
Finally, don’t be too quick to throw those legacy systems in the trash bin. If you’ve got projects in progress, it may be less disruptive for everyone to let some projects wind down with the software that is being used on it. Make sure you’re going to give the project manager some benefit by switching his in-progress project data from one system to another before you mandate the change. If you’re keeping those legacy systems for awhile (and many do) then make sure there’s a firm plan to retire them once they’ve fulfilled their function and make allowances for moving their data and training the personnel working on them at a later date.

Conclusion
All in all, deploying a project management system can be an exciting time as the new features and functions start to impact the way you do business. It’s an opportunity for an organization to become much more effective but it’s also not risk-free. Make sure you take the time to plan before you leap.

In our next issue, I’ll be looking at how to weave your way through the myriad categories of project-oriented software in order to choose the one that’s right for you.

Integrating a Project Management Software System

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 I don’t prioritize?

 

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

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

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

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

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

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

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

The result?

This:

clip_image004

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

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

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

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

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

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

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

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

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

  1. If you want to prioritize projects, forget about just giving them a ranking or some number, doing so just makes all the project sponsors crazy as they argue why their project should be a priority 75 instead of 92. Instead work with senior management so they agree on what business factors affect the importance of projects. Some examples might include:
  •  
    • Return on Investment/Profit (an obvious one for private firms)
    • Project risk (again pretty obvious)
    • Technical competitivWheteness might be a little less obvious
    • Client satisfaction
    • Strategic advantage to the organization
    • Reduction or avoidance of threat to the organization

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

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

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

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

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

 

Microsoft moving from Newsgroups

They were all the rage in their day but it seems that the era of the Newsgroups is gradually coming to an end.  For those who have followed Microsoft’s Newsgroups for microsoft.public.project, microsoft.public.project.server or microsoft.public.project.developer they are all being migrated this summer to new Forums hosted by Microsoft.  Here’s where you’ll need to go to keep up with these newsgroups as of the summer of 2010:

Project Newsgroup Project Forum
microsoft.public.project
microsoft.public.project.server
microsoft.public.project.developer

Collaborating Conundrum

It’s the hot button lately in project management circles. How can teams collaborate? It’s not idle chatter. It’s been apparent for a long time that a project manager’s role is not just calculating a schedule from his hidden laboratory deep in the bowels of the organization. Now a project manager is expected to spend the vast majority of his or her time working with others. They may be negotiating with the clients or recruiting new team members or empowering and encouraging the team to be more effective or referreeing resource conflicts with resource managers. And that’s just one-on-one or with small groups. The project manager is also expected to speak publicly to the board or the media or the users or the team.

With collaboration being such a hot button it’s not surprising that project management software publishers and consultants are happily explaining how wonderful it will be for clients to improve their collaboration tools. I get such requests on a regular basis.

So let’s pause a moment and just review what collaboration means and what implementing better collaboration entails. Dictionary.com has a couple of definitions of collaboration but the most useful to this discussion is: “To work together, especially in a joint intellectual effort.” Not too useful for practical purposes but the idea is having people work together. Well, a project almost always involves people working together so we know we’re off to a good start. What might team collaborators collaborate on?

A few categories of how teams might work together might include document management, meeting management, communications follow up or working with virtual teams. Let’s tackle a few of these:

Document Management

One of the most popular things pointed to when talking about collaboration benefits is document management. In many project environments, moving documents around numerous participants in the project team can be a critical success factor. In high tech, these might be design criteria. In engineering, they might be archtectural plans or engineering drawings. In bio-research they might be regulatory documents. It seems attractive to link these documents to task reports when doing project schedule reports but the big benefits of this kind of collaboration process is managing the workflow of the document. Should this be part of your project management process along with schedule management? There are a couple of factors to consider. First of all, does your organization already have a document management system. Many large organizations do. If so, then going with the flow on a system that’s already deployed makes a lot of sense. Secondly, does your entire project team have access to it? This may not be so obvious. Many project teams extend beyond a single organization. If that’s the case, then setting up a parallel document management system for documents associated to the project might be more sensible.

Meeting Management

Meetings, Meetings, Meetings. They’re so common that many timesheet systems automatically include a meeting entry. (We get asked for one all the time with our own TimeControl timesheet deployments.) Having meetings is often collaboration by definition but how you conduct those meetings can make a big difference to the effectiveness of a project. Meeting management systems include numerous features such as agenda management, minute taking, meeting collateral management (such as reports that are submitted to be viewed by the partiicpants), attendance recording and even virtual attendance for those who are out of town. With so many organizations having to curtail travel and even inter-office movement in order to save costs and with so many project teams reaching outside the organization, an effective meeting management process and system can make a world of difference. Sometimes such meetings can have an immediate impact on the project inlucing changing priorities, changing resource allocation, updating risks and progress information. Just being able to record promises made in a regular project review meeting and being able to recall that information instantly at the next meeting can revolutionize project progressing. But, does this mean that that the meeting management system should be integrated into the project scheduling system? Possibly. The first place to look is to see how the meeting management process is integrated into the project management process. Then look and see if there is an existing meeting management system and if that system is available to all your participants. It might be more important to have meeting management linked to document management than to scheduling.

Virtual Teams

More and more we’re seeing project teams being defined outside of the walls and even the corporate organization. Teams might include the client and sub contractors and even regulatory authorities from outside the organization and executive sponsors and resources from within the organization. The team may extend not just beyond the walls of the organization, it might also extend into numerous time zones and even numerous countries. Just holding a telephone conversation can be a significant challenge if part of the team is just getting to work in the morning as another part is just leaving at the end of their day half-way around the world. Empowering the virtual team to work as a team can be a significant challenge that has to be addressed early in the project lifecycle. Being able to distribute documents, record virtual meetings for review by others offline, updating progress in multiple time zones and even just being able to deposit project deliverables and artifacts somewhere in a file management system that is managed and traceable can make the difference between a project that works twice as effectively or half. I have seen such virtual teams hum along at a breakneck pace, one group half way around the world is delivering aspects of the project that is being reviewed by a team on the other side of the planet in time to be updated by the first group as they return in the morning. It can move so fast that it feels like around the clock development and that too can pose a challenge. When the pace of work is twice as fast as some team members are used to, the project can go off the rails in an awful hurry. Systems need to be twice as vigilant if the work is moving twice as fast so deploying systems to allow that tracking to be done more effectively is essential.

Incident and List management

There are so many bits of data that get generated during a project that having a single place to track them can allow many people to connect quickly and effectively. Lists and artifacts can be almost anything. They might include commissioning lists, deficiencies, bugs, corrective measures or even just lists of team members. Having such information readily available to all team members can be a blessing. I’ve seen a number of projects where integrating such list management into the project system and having that system be outward facing; meaning available through the Internet improves the speed of managing those lists and identifying problems that must be addressed by other team members. Simple online list management can level the playing field quickly by allowing required intervention to be recorded that reaches any member of the team at any level. A process needs to be in place to prevent every team member from assigning incidents indiscriminately to executives but the ability to do so can make a project tremendously more effective. These lists are rarely at the level of tasks that are managed in the schedule yet they often are able to affect tasks in the schedule.

Communication with… everyone

Effective communication is everything to a project manager but when setting up your project environment its worthwhile to try to determine what kind of communication is appropriate for what kind of information. Will you be checking your FAX every hour? Is that how you’d like to transmit documents? Do you want everyone copying everyone on every email? Will you progress data in a physical meeting or can members dial in virtually? Will you be updating information via SMS on a cell phone or on an application on a smartphone? How about instant messaging? Just because you can instant message someone on their phone will you use this as a primary source of communication? What information should require instant messaging and if you’re going to use this does everyone on the team have access to the same instant messaging system and network? Figuring out your communications strategy before you start your project makes a huge difference.

Collaboration is a way of life in today’s project management world. Most project managers and project management offices don’t need a do-everything project management system but hoping that collaboration will happen by default is a fantasy. A smart project manager will organize how they want collaboration to happen before the project starts even when systems are already in place. Getting everyone onto the same page early often makes the difference between staying ahead of the project or living in reaction mode trying to catch up until the project is done.

The Keys to Key Performance Indicators

clip_image002Executives often ask me for the impossible and what they want is best exemplified by an often used phrase, “A sip from the firehose.” In most organizations today there is no shortage of data and in the project and portfolio management realm in particular we have a plethora of systems and processes that can generate data but no manager can possibly sift through thousands or even millions of records in order to determine what decisions they should make.

The result is that most significant decisions about projects including the decision to start the project in the first place is made on an ad-hoc basis.

The technique to avoid this is well known. Organizations should choose “Key Performance Indicators” (KPIs )which will surface information that is critical to making those business decisions. But, how does one choose those KPIs? How do you know that the KPIs you’re using are producing the result you require? Let’s take a look.

Choosing KPIs

First of all, where do we look for choosing the right Key Performance Indicator and how will we measure it? These metrics will be used in a variety of ways. We can use these metrics for distinguishing one project from another. We can use them in the project selection process, the stage gate process, the resource priority allocation process and the project review process. There is no limit to the number of things we could measure.

One place to look it through the main elements of PMI’s PMBOK (Project Management Body of Knowledge). In each section you might have possible measure that would lead to better management of the project.

In the Scope area, for example, you might have scope creep or scope change as a measure. In the Time area you might look at delays in the schedule. In the Cost area you might look at resource costs or Return on Investment. In the Communications area you might look at the timeliness of schedule updates or the status of project reporting. In the HR area you might look at Resource Variance or Resource Load/Overload or Resource balance. In the Risk area you might look at the volume of risk items and their severity or urgency and so on and so on.

Not every metric will make sense in every context. For example, in a private organization, projected Return on Investment might be a critical measure. In a public organization this might be completely inappropriate. There, citizen satisfaction or alignment with legislative requirements might be much more appropriate.

Some of the criteria for a good KPI would be this:

Ø The KPI reflects some element of corporate strategy

So, measuring ontime delivery might make sense in most organizations, but where corporate strategy is more focused on quality or safety, focusing on ontime delivery might result in management making decisions that are diametrically opposed to the corporate mission.

Ø The KPI is actionable

All too often we see organizations with spectacular dash boards containing lovely graphics and charts and, when we ask what action is supposed to happen if this indicator turns red or if the needle on that guage goes to the danger zone, no one knows the answer. The whole point of a measuring and reporting on a KPI is to ultimately take action.

Ø The KPI should result in obtainable objectives

Creating a metric which no one ever has a chance of getting out of the “red” and into the “green” makes no sense. It results in urgent emergency action day after day after day and ultimately is self-defeating. The objective that the KPI represents (overload less than 110% of availability for example) must be attainable.

Ø The KPI should be measureable

It’s tempting to make KPIs which are wholly subjective, where someone just plugs in a number or a color. If this is based on a feeling rather than some empirical measure, the KPI typically has little value and yet the decisions made on the basis of the KPI may be just as significant as those based on other empical measures.

Ø The KPI should not be duplicated

Just because we have a dozen different ways to display late schedules, showing all those KPIs doesn’t add value. In fact, it can be confusing and disruptive.

Ø And finally, the KPI and the actions associated with it should be understood by all decision makers. Having a common understanding among all the decision makers of what a particular measure and indicator means is critical to using KPIs effectively.

KPI Challenges

There are a number of easy mistakes that people doing this exercise for the first time face. Here are some of the most common:

Ø “Great news, I have hundreds of KPIs!”

This isn’t great news at all. Remember, what we’re after is a sip from the firehose. If you open the tap too far; if you let too much water through the hose, you’ll knock management from its feet and they won’t be able to absorb the information. Typically we look for a handful of KPIs. As Chris Iervolino, an expert in Business Performance Management (BPM) said, “Somewhere in the extensive negotiations of creating the KPIs, the ‘K’ got lost.” So, just because you can measure a thing, you don’t need to measure it.

Ø “Great news, we have only one KPI!”

Having too few KPIs is also not useful. There are always a couple of opposing forces and results that can be identified in the project management business and the whole point here is to make business decisions. Those opposing forces need to be identified and displayed in some way.

Ø KPIs are too subjective

There’s a strong incentive to invent KPIs for which there is no measure; no metric. The result is an indicator behind which is just a subjective decisions based on someone’s feeling or intuition. While many business decisions are made on a manager’s intuition, when we put subjectivity into a Key Performance Indicator, we take a subjective perspective and display it as an empirical or data-sourced result. The effect of this can be negative.

Ø The KPI has questionable completeness or quality

Imagine that we have a Key Performance Indicator that shows our resource capacity. The graphic shows the organization’s current status of all work and all resource availability and projects the expected over or under load of resources against our project and nonproject tasks in the future. But the indicator only has current project data for 20% of the projects. Another 60% of the project data is at least 30 days old and 20% of the data is missing altogether. Imagine what business decision might be made on the basis of this indicator alone and how potentially damaging that would be. When KPIs are displayed, we always recommend that there is some indicator of the indicator’s quality and the completeness of the underlying data.

Wrap up

The great news about applying the Key Performance Indicator paradigm to project and portfolio management data is that there’s typically lots of great data to choose from and the nature of the project management process results in a lot of that data being of very high formalized quality. That’s perfect for a productive KPI exercise.

If you’re getting started on choosing your KPIs, the best advice I can give is to start small. Start with 3 or 4 indicators and get the measurements of them, the display of them and the actions associated to them right. The benefits of doing this can be profound and don’t worry, you can always expand the number of indicators in the future.

Happy measuring!

 

That Elusive Proof of Concept

At least once a week I must get a request from an organization to advise them on how to proceed with a Proof of Concept for epm software. It can be for a wide variety of epm tools and the particular flavour isn’t relevant to today’s conversation. My approach to all of these requests is the same and it often makes the requestor take pause. “We’d be delighted to help with a Proof of Concept,” I’ll say. “Please describe to me exactly what you wish to prove.”

It’s an obvious question isn’t it? Yet, in less than 10% of the cases, does the requestor have an articulate answer. I’ll get a hundred variants on “We want to see if it will work for us.” or something to that effect. When I poke in a little deeper to find out what the person really wants to accomplish, there is a disturbing but remarkably common theme. In many, many cases, the person who is trying to do a proof of concept is hoping that they can quickly establish a working project system with the enterprise tool and that management will be able to see this miraculous tool working and providing such remarkable value that they will grant the hitherto unavailable budget for a complete deployment.

Unfortunately, trying to use a Proof of Concept deployment to convince management to commit to epm or an epm tool is almost never successful. There are a couple of problems that may not seem obvious.

First of all an epm deployment, even a tiny one that you may be thinking of for this Proof of Concept requires the support of management to have any chance of success. A deployment of epm is a tiny bit about technology and a huge amount about changing behaviour or culture change. Without the direct and unequivocal support of management, you may get the technology installed but you have no chance of effecting a culture change. This is true for a 10 user deployment as much as it is for a 1000 user deployment.

Also, some of the most popular objectives for an epm deployment such as Resource Capacity Planning simply can’t be delivered until all data is in the system. Oh, you can simulate it of course, and you can certainly show an example report but you can’t see even 1/100th of the possible value with only a tiny percentage of the data. Moreover, without management ready to demand that all users commit to the system, there is little chance of getting access to all the data anyway.

Doing an epm deployment which has a chance of producing any real value for the organization, is going to first require a period of time where senior management examines and then commits to the results they hope for from the system. We usually do this work in a vision session of some kind early on in the deployment. Without knowing what business drivers the system is expected to affect, we are in the dark as to what the epm deployment is hoped to accomplish. At best, we must use guess work or hit-and-miss targeting to hope that we find a function in the system that somehow touches a business driver an executive is committed to.

No, using a Proof of Concept for this purpose may be one of the least effective manners of getting management to commit to epm. There are numerous other alternatives. If you want to get management to get on board with your epm system plans, here are a couple of suggestions:

One of my favorite methods is to do a facilitated vision session. Both senior management and the senior project personnel usually attend although sometimes not together. The beauty of this plan is that the investment in actual money is usually very small. A vision session for epm can usually be accomplished in a couple of days. There is often some preparation work and always some post-meeting documentation but still, the investment of both time and money is comparatively minimal. The other great thing about this strategy is that no matter who the ultimate system vendor is, the exercise with senior management is never lost time. Working through the business drivers for the epm system is a critical first step and, the worst case scenario is that management and the project personnel discover that they’re not ready to commit to epm at this time.

Another strategy is to use one of the many Executive Circle types of events for management to find out more about these systems. There are events of this type hosted by almost every epm system vendor but also from associations like the PMI or others. For example, the American Management Association has recently taken a more significant interest in project management and executive seminars by this group would be a great way to introduce the concept.

Visits to other organizations that already have epm where your executives can meet their executives are also tremendously effective in this area. Not only can your executives hear about how the epm system worked for another company but they are often quite gratified in being able to network and share concerns of all types. EPM system vendors can almost always broker this kind of visit for you.

Now, if you’ve gotten this far into the column and you’re a little ticked because you don’t actually fall into this category and your proof of concept plan falls into that 10% of cases where you do know what you want to prove, well fear not, I haven’t forgotten you.

If you actually are proceeding with a Proof of Concept, here are a couple of tips to making it successful.

First, make it a project. I know it sounds silly saying this to project people, but you’d be surprised how often this kind of thing isn’t managed as a project. Do everything you’d do with any other project. Have an executive sponsor, get a budget, make a schedule, have fixed objectives. If you don’t do this, you can end up with a proof of concept implementation that drags on for months or even years. (I’m not kidding. I’ve seen such implementations go on for more than 2 years!)

Next, make sure you have not only created some objectives but also some measurements that determine what will constitute a pass or fail of the implementation. Did it do what you needed? If so, move on. If not, once you’ve exhausted the avenues available to you in making it work, close that aspect down and get to the next step.

Regardless of whether you’re looking at convincing management or proving technical functionality, make sure your Proof of Concept has a beginning and an end. Remember to use the right tool for the job. If you are using a Proof of Concept as a tool, it works best at proving something specific rather than convincing someone of a general concept.