Category: Articles

Home Articles ()

Article: Analysis vs. Commitment


Project Management tools are fundamentally either analysis based or commitment based.  Which one is right for you?

When we talk about Project Management Systems, it used to be that we were only talking about Critical Path Methodology Programs.  These are programs, which are primarily scheduling tools.  These days, we could be talking about any number of categories of software in the project management arena. 

I’ll not start trying to mention all the different categories of tools that are referred to as project management software but attendees at the annual PMI Symposium can get a feel for the diversity from the plethora of vendors in the exhibit area.

If we are talking about project planning or the management of a project that is underway, pm tools are going to fall into one of two major categories.  

Analysis tools
The first includes all analysis tools.  This includes most of the popular planning and scheduling systems that can be found on virtually every project manager’s desktop around the world.  Analysis tools such as CPM schedulers can be very important.  We need very little information to make their analysis engines work.  Fundamentally a task identifier, a duration and a logical sequence are enough to get a critical path schedule showing the earliest and latest dates when tasks will logically occur without affecting the targeted end date.

As important as this is, it is key to remember that this method of planning was designed over 50 years ago specifically for projects that were huge, where there was only one of them at a time and where resources were considered to be unlimited.  It goes without saying that most project environments now are not like that.

Still, it is no doubt important to see what the logical sequence of events should be regardless of how many projects are involved and, perhaps when many project depend on each other for resources or through interdependencies, then the logical sequence of tasks becomes even more important and certainly the calculated analysis of the schedule becomes key.

Commitment tools
It’s perhaps a strange term for a category of project management tool and I don’t know of anyone else using it but the category is real enough.  Imagine that instead of analyzing when a task should happen, you simply commit to doing something.  An agenda is a commitment tool.  Even if you are only making promises to yourself, you have made a commitment.  You enter something you promise to do and when it’s due to be completed.  If the promise involves someone else, you usually mark that down too.  Adding an issue to an issue management system, is using a commitment tool. 

Ok, you say, but I don’t use the analysis feature of my scheduling package, I simply drag the activity bar to its desired location, isn’t it now a commitment tool?  No. You are using a tool, which has as its core design feature an analysis engine and you are trying to use that tool to track commitments.  The problem is, unlike your agenda or, better yet, a project issue manager; an analytical tool is not designed to track your promises and your success or failure to meet them.  Don’t believe me?  Trying changing the status date or time now for a project in most schedulers and watch the bars magically move forward to today, thus changing your promise automatically.

There are many project management tools on the market now, which are not analysis oriented, and they are finding an important niche in a wide range of organizations.

Can’t I have both?
But can’t you use both types at once?  Can’t you mix commitments and analysis at the same time into one tool?

A number of vendors are trying but the mixture of these two types of data has the potential for enormous mischief.  The problem is that the data looks almost identical.  If a scheduling algorithm shows a task identifier, a description and some dates, how does one tell that from a task that has been promised for that date regardless of whether the analyzer says so or not?  Yes, you can mix data from different systems, but trying to mix data from an analysis engine all the way down to your daily agenda is rarely successful.  Software has been made to try it before from the largest vendors around and while it can work technically, the data doesn’t hold well together practically.

So what should I choose?
You shouldn’t be faced with a huge choice her to abandon one tool type or another.  While the data doesn’t merge together well for practical purposes, you can still get tremendous benefits from seeing and using both when used distinctly.  The trend in new tools is definitely away from analytical tools and more towards commitment based systems.  In order to be efficient, you’ve just got to make sure you interact with each type appropriately.

Article: Collaboration and Project Management tools

7252413It’s this year’s hot topic – “Collaborative Project Management Systems” – but what exactly does it mean and how should we deal with the wave of collaborative pm software tools that are arriving on the market?

I mean it’s like saying you’re American but you just can stand for Mom or Apple Pie.  Project Management is a collaborative process so it surely goes without saying that every project manager is in favor of a collaborative project management tool. 

The problem is, that project management software vendors are in the market too and now that someone has coined the phrase, it seems that 100% of project management systems are now “collaborative” project management systems.  Just how do you go about telling one apart from another and determining what collaborative functionality is important to you?

The first thing to deal with is to take a step back from your Internet-wide search of pm collaborative tools and think for a moment about where you and your project team need to be collaborating better.  Collaboration can take a variety of forms. 

Perhaps your projects are weak in the area of informing project team members, clients or sponsors about project information such as project progress, changes in strategy or targets etc.  In this case, bulletin board type functionality or group email functionality might be important.

Perhaps you feel that a two-way feedback from team members to each other and/or to the project manager or client needs improvement.  In this case an ability to chat on-line or to see who is currently available in an instant messaging type functionality might be of interest.

Perhaps you are moving a high volume of documents back and forth throughout the group and the management of key documents is what is slowing you down.  Ok, so it’s document management functionality that you could use.

Perhaps the statusing of your project is arduous and some kind of update tool from the end users to the project system would make you more effective.  Ok, then an on-line statusing and/or timesheet system would be what to look for.

Some clients have come to me and said, “But I need all of that!” why don’t I just buy an integrated-enterprise-wide-collaborative project management system?” 

Of course in some cases we will find weaknesses in how a project organization collaborates at all and in this case all of these types of collaboration might be critical but it’s worthwhile to note that regardless of the functionality available from these collaborative tools, there is always a culture-change component to changing the way you manage your business. 

For each of the scenarios above you can easily imagine how making such functionality available could inhibit the project process. 

A wave of on-online chatting for example, with everyone talking to everyone about everything they think hour by hour with the project client joining in to experience perhaps for the first time the angst that can overwhelm a project team in mid-stream.

Or perhaps an ongoing stream of instant messaging requests that keeps a team member from having an uninterrupted thought throughout his or her day.

Changing the way we do business is something that has to take into account the shear momentum of how things are being done now.  Change causes upset.  It just does.  Even if that change is for the better.  There will be people more or less interested in change but the comfort of knowing how things are done today makes many people reluctant to abandon that method of doing business in favor of something else.

The best way to go about taking advantage of some of the new collaborative project management functionality is to start with what needs the most help.  I was recently at one of the larger pharmaceutical supply companies in North America and found to my great interest that they had done exactly that.  This firm had determined that document management was the most critical area that required improving.  With all the regulatory requirements in the pharmaceutical industry, regulatory documents must often travel across countries, time zones and endure for a remarkably long time in good condition.  Also, the security of these documents is critical to a successful regulatory ruling.  It was the project management group but what they ended up selecting after a review of a number of project-specific tools was a document management system that was not originally designed for project work at all. 

Of course that’s not for everyone and many of the project specific tools seem to be credible products but the point I’m making is that you’ve got to decide for yourself what element of your corporate culture you need to change before trying to automate it.  Once you do, you’ll need to make a plan (I know, I know, project managers hate to plan their own systems) to implement that change that includes training, evangelizing and the use of course, of the software itself.

Articles: Services move in on technology


Services are a key factor in the success of pm software vendors.  With the trend towards certification how will clients know who has the skills they require?

I thought I’d spend some time talking about one of the most significant elements of technology deployment in the project management sector – services.  In numerous project management software vendors, the revenue from services outweighs the revenue from software sales.  Perhaps that’s a good thing.  After all, as I’ve said in these pages more than once, the difficulties in implementing enterprise pm software almost always has more to do with culture change than with feature implementation.

In virtually every enterprise-level implementation of project management software, a significant level of consulting-type services is required.  In some organizations, the skills to implement the selected system is available internally but in many cases, organizations look outside of themselves to find these skills.  The requirements can be extensive.  A consultant for the implementation of a project management system requires skills in: business analysis, project management methodology, technology, finance, human resources and, of course the product or products being implemented.  These skills are rarely all found in a single person so you’re looking at a collection of resources required in order to successfully implement the project system in question.

Just as with any human resources search, one of the first questions to be asked deals with the qualifications of the consultant whether he be internal or external and herein lies a problem.

There really isn’t a hard and fast qualification that ensures that you have found the right person.  It’s not to say that there are no qualification measures around. In fact, there are perhaps too many.

We should start, of course with PMI.  The PMP certification is certainly gaining popularity in North America and even overseas but what exactly does it mean when you’ve got your PMP certification?  Well, that you passed the exam, of course, and that you were able to identify sufficient proof of project management experience in terms of points to qualify.  Yet, there are many people who have passed their PMP who do not feel qualified to manage a significant project.  Even for those who do feel confident enough to manage a project, having the PMP certification does not necessarily mean that they have any knowledge of enterprise project systems.  The other skills we mentioned above, business analysis, for example, might be completely absent in someone who had passed their PMP.

Ok then, what other standards are there?  ISO has the 10006 standard and you’ll find elements of project management in the 9000 and 14000 standards.  Yet, the ISO registration is not an individual qualification.  Being ISO registered indicates that you have established a stable process.  That’s great but doesn’t indicate how to select the proper resources to implement project management software.

There are other courses of study.  Many universities are now giving courses in project management.  I’ve sent several of my own staff on such courses to ensure that they understand the basic building blocks of the industry.  On occasion I’ve been fortunate enough to even lecture such students.  Yet, it is clear from just speaking to these students that their training in university alone does not prepare them for implementing project systems.

Many product vendors in the project management software industry have certification programs for the consultants who train and install their products.  Choosing one of these people is a good bet that they know the product being implemented and how to train you to use the features in it.  The problem is that such consultants are often light on the other perhaps more significant skills such as business analysis or HR.

Knowing just about the product itself or just about project management theory isn’t enough.  There has to be some perspective on the big picture.  Some firms have gone to the specialists in business re-engineering, the big accounting/consulting firms.  Companies like EDS and Deloitte and KPMG are providing consultants with strengths in business analysis and finance but who are not as strong in project management methodologies.

And if that all wasn’t enough, we’re about to have yet another certification to deal with.  As we told you in these pages last fall, Microsoft is working on extending the reach of Microsoft Project into the enterprise project management systems arena following its acquisition of Enterprise Project from eLabor.  Microsoft’s Project team is a small, tight group and, if they had to follow the model of the other enterprise-level project vendors, they would have to expand instantly by as much as 10,000% in order to provide the after-sales services that enterprise-level purchasers of pm tools require and expect.

Microsoft is, instead, turning to its 3rd party solution providers, offering training and some level of certification in order to help interested clients determine the qualifications of the implementers.  With a focus on enterprise sales, 3rd party consultants for Project will need to spend more time and energy on project management process and methodology than has been the case thus far.

That Microsoft will be turning out “Microsoft Certified Project Solution Provider” experts isn’t huge news in itself.  The issue is the huge volume of MS Project users and the rush of newfound “experts” that this volume will attract.  Last year Microsoft sold millions of copies of MS Project, soaking up over 80% of the established project management software market.  Consultants who are attracted to the format will become more and more plentiful as time goes on.  The sheer weight of the numbers of consultants in products like MS Project threatens to overwhelm the numbers of more experienced project managers who one might find in an association like the PMI.

For clients looking to bring in outside assistance, the plethora of certification programs now emerging has the potential to become more of a hindrance than a benefit.  Certainly any client looking to bring in experts from the outside would be well advised to spend the time required on due diligence of the experts’ credentials.  References of successfully completed projects will carry more weight than certification at least for the near future.

For those of us in associations like PMI however, the opportunity to be a leader in the field is significant.  Perhaps we’ll see closer ties between the methodology aspect of PMI and the technical aspects of the tools available to project managers over the coming months and years.  Perhaps it’s an opportunity for strategic alliances in the future to ensure that the skills and lessons learned by project management professionals over time aren’t lost in the drive for easy to use project management tools.

Article: Deployability – a key to project management


Everyone seems to be talking about enterprise project management software.  Chris Vandersluis takes a look at a key element of an implementation plan for enterprise-wide pm software.

I’ve spent the last 24 hours in a project management software exhibition hall here in Toronto, Canada, so you’ll forgive me I hope for harping on what has become a bit of a cliché in our industry.  You know the one I’m talking about – Enterprise Project Management Software.  It must be the hangover from the ERP implementation craze that was the hallmark of the turn of the millennium or something because it seems that every software system available to mankind today is “Enterprise”-something.  Vendors are either selling an enterprise-wide system or they’re selling how to implement it. 

I’ve had literally dozens of attendees ask me questions on what “Enterprise” project management system would be the best.  Almost every product on display has the word Enterprise in its description somewhere but when I’ve asked what about their product made it “Enterprise” enabled, the exhibitors were hard pressed to find a good response.  At the Microsoft booth, a new Microsoft employee asked me if I didn’t think that Microsoft 2000 wasn’t more of an “Enterprise” product.   Even our own firm is touting its’ Enterprise timekeeping system.  Frankly I’m getting a little tired of it.

It’s not that I have anything against Enterprise products.  After all, as I mentioned, we do publish one.  It’s the notion that every project management software tool is an appropriate product to be deployed across the enterprise that has me annoyed.  When I travel to different parts of the world I have the privilege of meeting people who manage some of the largest organizations and some of the largest projects in the world.  For the last 17 years or so that I’ve been in this business, an enterprise-wide-work-for-everyone-universal project management system has been like the Holy Grail.  It’s almost universally desired by management as a panacea for everything you don’t like about the project management business.

“If only we had an enterprise project management system where all the data was centralized, I’d be able to see exactly who is available at any time of the day,” say some.

“Ah, if only we had an enterprise project management system, we’d be able to see our project status in real-time,” say others.

“But if we only had an enterprise project management system, everything would be on-time and on-budget,” think the rest.

What kind of system would it be?
Ok, you may not be that shallow, but think about how great it would be if all project management data from projects done in your organization over the last 10 years was in a centralized database in a format that you could immediately access, that you could see trends and averages in at any time.  Sound attractive?  How about this, imagine that all project managers who are managing projects that have any impact of any kind on either the scope, resources, or schedule of your own projects are using a project management system that automatically ties in with your own and shows the impact as soon as they know about it.

What very few people spend time thinking about is what implications are involved in actually deploying such a system. 

First of all, what kind of system would it have to be.  We’d  need a system that was:

  • a) capable of storing data in some centralized format such as a client/server database.
  • b) easy enough to use in order to be accepted by the huge numbers of part-time users who would have access to the system
  • c) robust enough in its functionality in order to handle the kind of complex analysis that is bound to come from managing large amounts of diverse data.

Next, we’d need to tackle the process.  If you’ve been working on this at all, you’ve no doubt come up against this issue in a big way.  The process by which all the data will be collected, entered, analyzed and distributed through such a system has to be walked through over and over and over again from the perspectives of everyone involved in the process just to make sure data can make it through the system.

Finally, there’s the matter of how it’s deployed at all.  It’s often a case of the shoemaker’s children who go barefoot when it comes to deploying a project management system.  There’s almost never a project management plan for it!

And just what do you mean by an Enterprise Project Management System?
Let’s look at these one at a time.  First with regards to the products themselves.  There’s no point in naming names.  (Please don’t be calling me to ask if I think that “Product A” or “Brand X” is really an enterprise product – the whole point of this is to let you figure out for yourself what’s important.  First of all you’ve got to look at the kind of product you’re looking for.  As I answered to someone today when they asked which was the best enterprise project management product, “What are you thinking of when you ask for an enterprise product?” 

If an enterprise product means simply something that will be used by the enterprise in the widest possible distribution, then looking at an of the easy-to-use desktop products is your best bet.  Make sure you narrow down your search.  Is it scheduling, resource allocation, document management, timekeeping or what that you’re hoping to implement?

If you’re looking more for a system that can be used centrally by a small team of professionals (such as in a project office) to manage all projects in the enterprise, then you’d do best to start your search among the high-end pm systems which were originally designed around mega project environments.

You may rather be looking for a product which will be widely distributed but will maintain all its data in some central repository for reporting purposes.  In this case, your search is not in vain but will take a little more work.  You’ll still need to concentrate on the ease-of-use of the interface such as in a desktop tool but one of your basic requirements will be data storage.  It shouldn’t take long to come up with a short list.

All these three definitions can be deployed with fairly low stress.  It’s the fourth one that causes grief.

If what you mean by enterprise project management software is an environment where the software is widely deployed and where project decisions are taken at different levels of the organization (e.g. resource availability decided centrally, but resource allocation decided locally) and where there are numerous levels of responsibility for data (e.g. the individual project managers manage their own small project but the global impact of all projects is the responsibility of someone at a higher level in the organization and/or if you are talking in terms like multi-project resource leveling, multi-project analysis, hierarchical project groupings and so on…  If you mean something like that, then you’ve got a much tougher challenge.  This kind of product is one which will almost certainly have to come in parts.  There’s got to be some part of the system that is designed to be used by the project office type of project manager.  There’ll need to be a completely distinct interface for end-users who will have only occasional access to the system.  There’s got to be robust reporting, flexible data structures and much, much more.

Getting started
There are a couple of such product combinations on the market today and while theoretically any of them might work, ensuring that the product combination you select can actually be deployed is the next challenge.  You should be able to get your short list figured out very quickly and once you do, here’s the hoop you should be making your project management software vendor jump through:  Have them describe to you (in terms even your management will understand) the process by which data will move through their system.  Be wary of cheap demonstrations.  It’s not difficult to create a demo that gives the simulation of the system working while obscuring key difficulties in making it work. 

A couple of years ago, I watched an organization struggle with a matrix organization problem.  They had divided their project data into individual sub-projects where no sub-project had more than one resource grouping in it or more than one project-phase.  This was so they could group it in one direction for the resource managers and in the other direction for project managers so that each type of manager could manipulate the data within their area of responsibility.  It had taken the organization months to divide up their data this way and they were abjectly miserable.  No surprise.  No one had ever questioned how each type of manager with their own distinct and often conflicting responsibilities would be able to access and manipulate the project data.  No one had used up some inexpensive white board space to map out the flow of data like a process.  The organization’s still struggling with the concept.

Now, I know I’ve said this before, but here it is again:  You’ve got to consider how you’re going to deal with the deployment of your chosen system(s).  If the system you’ve chosen can only deliver its first results once it has been adopted by 100% of the organization, then you’re in for some bad news.  In the majority of cases, project management software implementation projects that are designed as an all-or-nothing approach, deliver nothing.  It can’t be much of a surprise.  The cultural impact of trying to get everyone in an organization to change from anything to anything else at the same time is horrendous.  Look for the small victories.  Make sure that you’re going to be able to get some value out of the product while it’s being deployed.  It’s true that there’s a good chance that you won’t have 100% deployment but the good news is that your system will be delivering some value to the organization even if you don’t.

Finally, work on breaking the trend of not using what you know on your own projects.  The best advice I can give you on how to be successful in implementing an enterprise project management system is to use all the project management techniques while doing so.  Almost everywhere I go, I find virtually no project management being applied to the project on implementing project management software.  Be the first.  Break the trend!

Article: Batteries not included

duracell_batteries_setArticle: Batteries not included
When people used to buy large-scale project management systems, buying the training was just part of the cost of doing business.  The cost of training compared to the cost of the software was a fraction.  You might spend only 10% of your software investment on training of your personnel on the proper use of the project managemnet system.  As project system have become cheaper the percentage people expect to pay on training has stayed the same but it buys much less training.  This article looks on the phenomena I call “Batteries not included.

Read more…

Article: Collaboration Systems means learning to play together

sandboxCollaboration Project Systems seem to be available on every corner but are we ready to use them?  This article looks at the challenges and pitfalls of implementing a collaborative project system.

It seems to be the subject on everyone’s lips – when will your organization move to implement a collaborative project system.  Virtually everyone’s getting in on the act.  At the project management seminars, every vendor appears to have an “enterprise project management collaboration system”.  “Enable collaboration!” we cry when the clients come near.  It all sounds pretty great and there is no doubt that the executive suite is finding the message very attractive.  ‘Just purchase our enterprise-wide license,’ explains the vendor, ‘and your entire project group will begin collaborating.’

Ok, perhaps I’m being a little facetious but the truth is, that’s far too close to the truth!  So you’re wondering if your organization shouldn’t get on the bandwagon and see if they can implement a collaboration system?  We’ll cover a primer on the subject in this column.

First of all, what is a collaboration system?  The answer is, of course, different for every system vendor but at its root, such a system extends classic project management functionality by allowing a degree of interaction between the project team members and both the project manager and each other.  Most systems do this by enabling several types of functions.  Given the ubiquitous nature of the Internet, virtually all of these functions are enabled by the universal interface of the web browser and the universally available network of the Internet itself. The first function, and the most obvious, is an alert mechanism that informs team members that something about the project that affects them requires attention.  This might be a new assignment or a change in schedule or just a reminder to get their timesheet completed.  Next you’ll find some kind of updating ability – allowing all team members the ability to enter status data for the project.  This might be as simple as a timesheet or extend to every aspect of task progress.  Finally, there is usually some kind of communications mechanism such as a Forum, or live chat typical of most web portal technology.

Where can you find this Holy Grail?  Everywhere I’m afraid.  This kind of functionality is now becoming quite common.  You’ll find it in everything from SAP to Oracle Project to Primavera’s suite to Microsoft Project Server and a lot of places in between.  There is even a range of open source solutions that provide this functionality.  This type of code can be found at  (There is usually some assembly required.)

You would think with this kind of functionality readily available – in some cases for only the cost of implementation that this wouldn’t even warrant an article – there would be no question – of course everyone is already doing this! 

This is not the case.  If you haven’t successfully completed the deployment of your enterprise collaboration system and are feeling terribly inadequate so far, take heart.  You are not alone. 

The challenge in implementing and deploying such a solution is not often in the technical arena.  The challenge is in the very nature of collaboration.  Some executive types might imagine that team members don’t collaborate with each other because they are missing some critical function in the enterprise systems.  It’s much more likely that team members don’t collaborate because the culture in which they work provides enormous disincentives to collaborate. 

Many organizations (the larger, the more likely) have gradually bred inherent barriers for employees to share.  These may include any of the following:

Power struggle
In some organizations, information is power.  If I tell you everything I know, but you don’t do the same with me, perhaps you can use your increased access to information to forward your own career at the expense of my own.  For example, if my project is currently running slightly late, you might be able to share that information privately in some circles while explaining that your own projects are right on time.  I might never get the opportunity to explain a perfectly valid reason for which my projects are late before finding myself out of a job.

Beaten by my own data
In some organizations, sharing bad news is tantamount to shooting yourself in the foot.  Some project managers will be unwilling to share schedule or cost project difficulties in mid-project for fear management will be in their cubicle in the morning replacing the project manager or micro-managing the project from now on.  Given that some projects often go through both positive and negative periods, project managers might have the experience that waiting until the final results are in would be a better strategy – who knows, the project might end up better than we think, or perhaps there’ll be a change in scope tomorrow that will hide the project problems or perhaps my manager will get promoted and a new guy won’t have a clue how we’re supposed to be doing.

The mythical 40-hour day
In many organizations, particularly those in the high-tech field, there are often a very small number of ultra-key resources.  Without these people, the core of a project is undoable.  This might be someone who has intimate knowledge of the legacy systems’ architecture or someone who has a particular mix of skills and knowledge to be able to perform key design and construction of the kernel of systems.  Sometimes it is a particularly clever person who knows how to do a certain type of calculation (writers of resource leveling algorithms come to mind).  In a multi-project scenario (virtually every high-tech firm has one) every project manager schedules these resources at 100% of their time.  It’s very common when putting an enterprise project system together that one of the first results is finding out that a small handful of resources are scheduled at 200 hours per week.  The project managers who have been able to get access to these key resources often do so with the finesse of great interpersonal relationships, friendly persuasion and so on.  These are the most productive project managers and if we deploy a collaborative project system where they will have to share their true resource requirements with everyone, these resources will become harder to hold onto exclusively as they may have done in the past.  So – these project managers must resist such a system regardless of its benefits.

If you think of all these effects, they are the very things management wishes they could remove and the very thing that the culture of the organization will try to keep in place.

Aside from the cultural barriers, there are other challenges for a collaboration tool deployment.  The technical issues can be significant.  Yes, it’s true that end-users who see such systems enjoy a very comfortable level of interface as the ease-of-use of such systems is usually excellent.  But for all of that, the installation and architecture issues may be challenging.  You should be considering:

Client Hardware/Operating System/Browser compatibility
It may all look great in Internet Explorer but will you have some users (perhaps out of the country) who will be trying to collaborate using a Mac OS9 with Netscape?  You’ll have to check the systems you’re implementing for such compatibility issues.  You need to check the hardware, the operating system, the browser and sometimes even the Java Virtual machine versions to ensure compatibility. 

This is particularly poignant if you are considering a system which must be “outward facing” meaning that users will access the system from outside your corporate firewall through the Internet.  If not well architected, not only might the security of your collaboration system be compromised, you might open a path to other corporate systems.  You might need to consider VPNs or other security measures.

Bandwidth, connectivity
What kind of network traffic will the system generate and is your network ready to handle it.

Hopefully you’re still reading and I haven’t scared you off.  If you plan to deploy a collaboration system, here are some tips to avoid the worst headaches:

First, make the deployment a project and treat it like every other project in the organization.  This includes having a sponsor, a charter, a budget, a schedule etc.

This type of deployment should be managed as a change-management project.  This is not an uncommon type of project – it’s just like any major change in process – but if you treat it this way, you will avoid a range of errors that are bound to occur if you treat this as a simple software installation.  Remember, unless you are a brand new startup (and even sometimes then) your organization already has a way of working that has its own momentum.  You will find it easier to gradually redirect the momentum into a new direction than you will to simply stand in the face of it hold your palm up and say ‘talk to the hand’. 

For those issues which are bound to be contentious, get buy in from many sources.  Go out of your way to encourage input.  Nothing will get someone’s back up faster than to deliver an edict that you have to deploy through threats and force.

Make sure you manage expectations. Leopards don’t change their spots overnight and not everyone wants to share all their data.  Management in particular needs to understand that the change in culture will occur over time and they will have to contribute their patience for the project to succeed.  If you are in system selection mode, put a heavy emphasis on flexibility over functionality.  It’s fair to say that the way you use the system in the end will be heavily influenced by the users themselves as it is deployed and you will be happy you can flex with their demand as it evolves.

Finally, get help.  The system vendor of the product you select will have numerous resources available and consultants, if used sensibly, can often get a message across that is difficult to hear from someone inside the organization.

Article: Has CPM had its day?


Critical Path Methodology has formed the heart of most of today’s modern project scheduling systems.  Is it time for something new?

 Many of us remember what it was like; Aerospace and Defense were spending money on a scale never before seen in peacetime.  Construction and infrastructure projects were beyond comprehension in their scope and vision.  It started in the 50’s and lasted until the end of the 80’s.  It was the era of the mega project.  It started with a post-war world and saw us through the cold war and the placing of a man on the moon and the birth of the modern computer.  It saw power projects that harnessed rivers and atoms and for project management as a discipline, it was a time of coming of age.

Project management has been around of course as long as there have been projects.  The Pharoses used some kind of project management on the creation of the pyramids and I’m sure every great project has seen some kind of management since the dawn of time.  But never before in the history of the world have so many great projects happened simultaneously.  No, history will record the birth of the discipline of project management in the middle of the last century – circa 1950.

The birth of CPM
For those of us who were able to work on some of those mega projects, you can remember how they were organized;  First of all, there were lots of activities.  I mean lots.  There were effectively unlimited resources.  Those resources were expected to work across multiple years to accomplish their task.  Time was the only constraint and the pressure to finish early, finish on time, not to be late drove everything.  If you were in aerospace it was the “space race”.  If you were in Defense, it was the “arms race”.  If you were building infrastructure to accommodate the new world it was about finishing fast enough to just keep up with demand. 

It was into this world that Critical Path Methodology was born.  It was miraculous.  For the first time, we could look at a project and know just what tasks we had to focus on in order to avoid delaying the project.  We learned about forward and backward passes and early vs. late dates.  There were variants and innovative displays.  Gantt had his bar chart and the US navy came up with PERT.  It was all designed to focus on one thing – “Don’t be late.”

Early computerized CPM systems
The application of computers to this calculation methodology was a natural.  With all the calculations to do, it seems obvious.  In fact, as computers have evolved, one of the first business applications to appear in each new iteration has been a project management system.  Computers were tailor made to handle the arduous yet clearly defined calculations, enabling project teams to adjust their forecasts as fast as events occurred.

Yet these systems were created in the world of the time.  Project Management Systems they were called and, indeed, they were in the project management category but what we all knew we meant was that these were CPM scheduling systems.

Those first systems didn’t look much like the graphical, easy-to-use systems of today.  The earliest systems on mainframes and mini-computers were originally loaded with punch cards.  Even once “on-line” systems became available they looked more like an airlines reservation system than today’s point-and-click.  The fundamental algorithm though of those original scheduling systems is essentially unchanged over the years.  Even as systems became available on PCs they showed the bias of the times.  Early project scheduling systems didn’t do resource leveling.  It was a later invention.  In fact, with some systems, the resource calculator was sold separately as an add-on.  Resource-limited scheduling?  It was an afterthought.  Remember, resources on a mega project were essentially considered unlimited.  There was no thought of scheduling all the way down to the individual level.  Resources were considered at best as disciplines or categories.  Graphical reports were considered a luxury that not everyone wanted or needed (Can anyone say “Primavision”?).  These days we talk about resource calendars and split activities but there was nothing like that in the thinking of the time.  I remember the first system I worked with having 8 calendars – Whatever would I do with all those calendars? I wondered.  Baseline changes were also something not originally conceived.  No one much cared how the mega project had originally been planned.  All that counted was when it would be finished.

The PC-based software that got its start in the early 80’s is still very much a part of today’s market.  And, while those products have advanced with the times, for those of us who have seen those products since their first versions, we can see the traces of their original design.

Yes, it was a different time but the software we see today had its start there and for the most part, the changes we’ve seen over years in that software have been an evolving theme rather than a re-thinking for the times. 

Welcome to a new world
The world that project managers face today is a far cry from that of the 50’s through 90’s.  It is a function of today’s economy.  Today’s MTV generation lives in a world where 10 year long projects are remarkable exceptions.  Where an individual is more likely to be working on multiple projects at one time – even multiple projects in a single day.  It is the world where time to market, shorter run times, design/build, RAD (Rapid Application Development) rule – and it is skewing everything we know about project management.


While the world was changing for project managers, the world of computers was changing too.  We tend to think a lot about the impact of Windows on the current landscape and of course with that thought about Microsoft must come a thought about MS Project but when you look at the core, the most significant changes in project management products have been interface-driven.  After all that was Windows’ claim to fame.  It made the PC interface so easy that a whole new category of user was able to adopt it and become proficient with must less training.  Changes in project management software have been focused on these areas.  On-line tutorials, user-friendliness, flashy, sexy, fun to use software make for more sales.  Yet, the basic concept of the vast majority of these products continues to be based around the old CPM model.

Microsoft tried to break out of the model a couple of years ago.  There’s a famous (infamous?) white paper written by someone at Microsoft from a few years ago describing how MS Project version 3 “de-emphasized” the CPM model.  It may be true, but if you do a calculation of schedule in MS Project, guess what algorithm is used.  No – at its heart MS Project is still a CPM product.

Sure, there have been plenty of additions and enhancements in all of the project management products popular today.  Some of them are remarkable.  Projects can now be huge and many high-end tools do multi-project scheduling.  Forget about 8 calendars and a single baseline – “unlimited” is the latest limit described by almost all PM software vendors on such functions.  There are hierarchical resources and integrated costing functions and risk analysis and so on and so on.  It’s remarkable but at its heart, most of these systems are still built around that original CPM algorithm. 

The CPM algorithm requires a few key elements in order to automatically calculate a schedule: It requires a list of tasks.  For each task, a duration or a method of calculating the duration must be given.  If there is a logical sequence to the tasks, this must also be defined and, given this information, a CPM calculation can tell you the earliest feasible date each task can start (and finish) and the latest date it can start (and finish) without delaying the project as a whole.  Resources may be defined along the way but basically the resource calculation is laid on top of the CPM dates and scheduled from there.

It sounds fine but remember the algorithm was designed in a period where the only driving criteria was “don’t be late”.

“And now, for something completely different”
Imagine a world where the driving criteria for successfully completing a project is the availability of highly skilled individuals.  A world where even the technology a project is based on will change multiple times over the life of the project.  (Sound familiar?)

I question whether the Critical Path Methodology algorithm is a useful method of analysis for many of today’s projects (Wait.  If you’re one of those Critical Chain advocates – please don’t be writing me explaining how different it is – I don’t believe that’s the answer either.)

In a world where skilled individual resources move from project to project over a period of hours – perhaps we need a whole new way of thinking about project management software.  It would have to be a completely new paradigm.  Something starting not with a list of tasks perhaps but with the capabilities of the resources and technology available to us.  Perhaps the projects and tasks one commits to and the schedule that becomes possible should be driven around available technology capacity and skills rather than the other way around.

There is a great focus at the moment on the Internet and the Web and how marvelous it is to be able to work across a world-wide network.  The focus is all too much on the interface for my tastes.  It makes for sexy press and I’m sure I’ll end up being a user or proponent of some of these systems.  I don’t doubt that there is merit in many of them; but it is a variant on a theme.  Being able to look at the same old paradigm in a web-browser is not a shift in thinking no matter how many new people will play with it because it is simpler to use. 

There is room in the project management software market I think; room for some innovation; room for something completely different.

There are a couple of firms, some new and some old who are touching on some of these new areas.  Some of these solutions are innovative but many were not ready for prime time.  I’ll be looking for developments from these firms throughout the year to see if they can get over the initial teething stages and get something into the market that addresses the new world we’re working in. One thing for sure, when there is a need in the marketplace, someone will find a way to fill it.  When I find some answers, I’ll let you know.

Article: A Letter to Santa


Here are some trends in project management software we’d like to see Santa deliver this year.

Well it’s December at last and thoughts naturally turn to the Christmas season.  I’ve always found it interesting that among other projects, Christmas morning never seems to be late.  I mean when you compare your family project of getting presents for the kids, trimming the tree etc. it’s interesting that all of the circumstances that seem able to stop other projects never seem to appear.  You never hear on Christmas morning, “I’m sorry kids, due to technical reasons, Christmas has been postponed a few days.”  Hmmm, the power of Christmas.

I figured that if Christmas is this powerful for project management, then perhaps a letter to Santa on some trends I’d like to see for the next year might find a friendly ear.  It’s not for me of course, just a few things all of us might use for

So here’s my list:

Dear Santa,

I’ve been awfully good this year and instead of asking for something just for myself, I thought I might ask you for something I could share with others in the project management industry.  It’s been a challenging year for project management software vendors and I thought if you and the elves could spare some time, you might be able to find a way to get the following into my Christmas stocking:

My first request Santa is for the pm software vendors.  Is there any way you could get them to all use the same language?  It’s tough enough trying to figure out how these systems work without everyone using different terms for the same thing.  I mean is a task an activity or is a resource budget the same as a requirement?  Is availability the same as a profile?  It’s been confusing Santa and if you could just give us a common lexicon that everyone would promise to follow; we’d have an easier time of it.  It’s not just the list of terms we’d need Santa.  We’ve got too many lists is the problem.  If only everyone could use the same one we’d have it made

While we’re talking about language, the Earned Value people could use some help again.  Is there any way you could help them to use more actual words in their industry?  It’s bad enough that every couple of years, they rename the guidelines they use to define the industry but the acronyms they use reminds me of what Norm Augustin once said.  You remember him Santa?  He was the chairman of Martin Marietta Corporation and once wrote that ‘Acronyms and abbreviations should be used to the maximum extent possible to make the trivial seem significant.’  Now, I’m not trying to say the Earned Value movement is trivial but when a sentence like “While looking at the ACWP and the BCWP in our our SV and CV reports this month I’d like to update our BCWS to get closer to our thresholds.” makes sense, isn’t it time to try to get back to some simpler language?  I mean surely the Earned Value movement must wonder why more people haven’t adopted what is clearly a very powerful method of evaluating project progress.

Santa, I think the software developers have been innovating but frankly it’s tough to tell based on their marketing people.  Apparently this year “collaboration” is in and “desktop project management” is out.  I know lots of people have been asking you for a project management tool of one kind or another under their tree this Christmas.  But Santa, do you think you could get the marketing people of the different vendors to each promote something different so we could tell them apart.  I get so confused at the PMI Symposium in the Exhibition hall when every booth says they have “Enterprise-Wide Collaborative Project Management software” that say they integrate with everything from my finance system to my watch.  Surely there must be some differences between all these products?  Is there any way you could send the marketing people back to classes to learn that first critical lesson called Segmenting the Market?

Also Santa (I know I’ve already asked you for a lot.) is there any way to convince project management software vendors that project management just isn’t that user friendly?  I mean it’s a complex concept at best but according to many of my software colleagues, even a four-year-old could have manage the construction of the Hoover Dam if only they had a copy of whatever pm tools they’re promoting.  Perhaps you could cut the project management training people a break and let prospective project managers know that they are probably going to need some training.

Finally Santa, just one thing for me; Is there any way you could give me something that would help my project get in on time and under budget?  I’d sure appreciate it.

Thanks Santa and Merry Christmas!


Article: The Project Manager Salesman

salesman_cartoonOne of my own mentors told me a very long time ago, “You don’t like selling?  Too bad ’cause you’re either you’re either gonna be selling to them or they’ll be selling to you.” 

 There is a disdain for salespeople among many who think of themselves in more of an engineering context but my experience in the project management industry over the years has shown that my mentor’s comments to be more often true than not.  As project managers we are going to need to sell our story often and in many different ways.  Here are just a few project management sales opportunities:

 Selling yourself as the project manager
Audience: The PMO, Senior Management and/or the Client
Before the project even begins, you’ll need to convince someone that you’re the right person for the job.  Do you have the experience for this kind of project?  Do you have a resume of the skills and particular contribution you can make if they put you in charge?  What about the resources you’ll need when you take on the job?  Are you ready to make a pitch to management for the particular tools or assistance or people you might require? T his is your chance to sell that idea to management!

 Selling the proposal for approval
Audience: The Steering Committee
You’ve got the project but is it a project yet?  If your organization does project portfolio management then perhaps not.  Many organizations use a Stage-Gating system that starts before projects get very far.  Are you ready to make the case for your proposal to become a project?  Have you got a business case that lists the Return on Investment, the Strategic Alignment of the goals of this project with those of the organization?  Do you know how your proposal compares to others you may be up against?  How can you make your project look like the most attractive to the steering committee who needs to approve it.

While we’re talking about this kind of salesmanship, we should add the same for each and every stage-gate that the project will encounter.  You’ll need to present more than a barchart to get your project through the gate and into the next stage and that may mean preparing materials and a presentation to show why you’re ready to move to the next level at each review.


Selling the budget
Audience: Senior Management
Ok, you’ve got the project, but do you have the resources?  This is one of the most fundamental challenges for project managers and a remarkable percentage of project managers aren’t ready to make a case for the money they need.  Are you?  Do you have the backup research to say why you need each and every penny that’s in your budget?  How about a trade-off spreadsheet of less money equals less features equals less return on investment?  It’s an easy tool to understand and very few project managers think of doing it.  I’ll put selling the scope of the project and the timeline into this same category although you might have to make separate pitches for each. 


Selling the project for resourcing
Audience: Potential team members and Team/Department Leaders
It’s a miracle!  You’ve sold management on your project and you’ve got the money you asked for and a schedule you can live with.  Now who will actually do the project?  Can you attract the best team members?  Can you lobby the key skilled resources you’ll need?  How about the Team Leaders who might be in charge of those resources?  Have you thought of how you’ll pitch to them to get that particularly key resource?  What’s in it for them?  Why will your project need that person and how will that help the organization as a whole?


Selling any variance or change management
Audience: The Client
As you’ll know if you’ve read articles by me in the past, my favorite project management quote is from Napoleon Bonaparte who said “A battle plan lasts until contact with the enemy.”  That’s almost always true on a project.  When you do get some variance or there is a request for a change of scope, are you ready to pitch the idea to make the change to the client?  Perhaps what would be best is pitching the client to not make the change.  Do you have the materials, the logic, the presentation slides and the story that’s easy to understand and ready to deliver?  Perhaps it’s a time-to-market vs. feature-rich trade-off analysis.  Whatever it is, it’ll need to be easy to graph and easy to absorb.


Selling the end-product
Audience: The Client and/or End Users
Hurray!  Your project is finished.  Or so you think.  I can’t tell you how many project managers get to the end of the project only to find the client reluctant to accept what was created.  “But we made what you asked for,” says the project manager.  The client doesn’t see it that way and the project manager isn’t ready to sell the end result to the client.  Are you?  Have you been getting the client ready for what they’re about to receive?  Have you got materials that you can provide for sign-off, for the benefits that they’re about to get?  I’ll include here selling Phase 2 of the project because it often happens at client sign-off. 


Selling yourself as the project manager for the next project
Audience: The PMO and/or Senior Management
Finally, when the project is over are you ready to sell management on how great a job you did so you can get onto the next great project?  Did you collect data along the way of what you accomplished as a project manager and how you made a difference?  A lessons-learned document that gets widely distributed is a great tool for this.  Share your lessons with others but don’t forget to point out the things that worked along with what didn’t.  It’s a wonderful opportunity to explain the system you created or the tools you shared with other team members.


Regardless of what part of the project management cycle you’re in, the chances that you’ll need to do some sales work as a project manager is almost inevitable.  Do you have the tools and the skills?  Here are a few that I often find lacking when I interview potential project managers and even independent consult ants:


Presentation software
Whether it’s the ubiquitous PowerPoint or other presentation software I’m always stunned at the horrible quality of slide presentations.  Projected presentations are a fact of life.  If you don’t have the graphics and design skills to make your own unique templates, look for some online.  There are thousands of free templates and a low-cost investment in PresentationPro or other template warehouse is worth its weight in gold.  While I’m talking about presentations, learn not just how to use your presentation software but also some basic functionality of graphics software such as PaintShop Pro so you can capture and insert corporate logos or screen shots or pictures of the project.


Public Speaking
I spent about 10 solid years of being trained in public speaking and while that’s more than most people do, I talk to an incredible number of project managers who’ve spent no time at all.  If you can’t speak in front of a small or even mid-sized group, you’re always going to be handicapped as a project manager.  There are great training courses that are not tremendously expensive.  Join Toastmasters or Dale Carnegie or just look online but get a professional to give you some basic speaking and voice lessons!


Word Processing skills Document writing
A project manager has to be able to write a proposal or business analysis report.  Expecting that the spell and grammar checker on your word processor will do all the work for you is a fantasy.  I see a remarkable number of documents that are terribly formatted, poorly written and just plain hard to understand.  If writing is not your thing, you can sign up for a business writing class at your local college.  And, for goodness’ sake, learn the basics of your word processing package!


Even for skilled project managers, there are a few sales tools that you might not often think of but that can be invaluable.  Here are just a few that I see project managers collect very infrequently but that are incredibly impressive when used appropriately:


Data collected to make one of your sales points for any of the sales “opportunities”
Project managers who collect data along the way always do better at presenting it.  If you are thinking ahead to your next presentation then the more empirical data you have available, the more convincing you are.


Competitive Advantage
It is inevitable that when you are selling in one of the opportunities I described above that the people to whom you are presenting will be looking at what you’re presenting in the context of alternatives.  It’s very powerful to have thought in advance of what those alternatives are so you can present the competitive advantages.  You don’t need to talk about the alternatives such as other project.  But, you can still talk about those aspects of your project that would compare well against others.


Competitive Benefits
Aside from advantages, one perspective that even trained sales people often forget are the competitive benefits.  If you think of not just the advantages of your project over another but also the benefits that the organization will realize in your proposal vs. another you’ll already be head and shoulders above whoever else is presenting.


There are so many free survey sites such as Zoomerang online but so few project managers use them.  I’ve seen experienced project managers leap ahead by collecting survey results.  The surveys might be for feature comparisons, interface element selections, timing or prioritization by clients or users.  I saw a fabulous survey done once just for icon selection within a software project.  Surveys don’t take a huge amount of effort but their results can make a very big impression!


Whatever the project, you are bound to run into some situation where you’ll need to become a project manager salesperson.  Learning the sales tools and skills even at an elementary level can make the difference between a successful project and one that’s less so.  So – get out there and do some selling!

Article: From small projects, large projects grow

acornThere’s something compelling about the big project, the huge project, the significant project.  There must be because almost everywhere I go, people take little projects and try to make them bigger. 

 It might start innocently enough, the project team brainstorms in the early planning stages and a mind-mapping exercise takes the little project and gives it branches from the main idea and the branches grow twigs and the twigs grow leaves and before you know it, it’s blocking out the sun!

 Or, perhaps a consultant might have thrown in his two cents.  “We should do something magnificent,” he might say (thinking of how many of his colleagues might be able to join him on the job.)  “It’ll be a project that endures through the ages.”

 Whatever the cause, before you know it the initial idea has now become a humongous idea and the size of the project carries its own risks.  The more complex a project is, the more likely it is to fail.  We talk a lot in here about being effective, about using our systems to make us as productive as possible, about using resources expeditiously.  I’m pontificating all the time about how we can handle those big projects and tackle even bigger ones at the same time if only we could use our project systems most effectively.  If we think of the 3 sides of the project management triangle: Scope, Time and Resources, we’re always talking about fixing the Time or Resource sides.  The one we almost never talk about reducing is “Scope”.

So today:  a few thoughts from the chain gain on turning big rocks into little rocks.  Yes, that’s right, making a smaller project out of a larger project.

Let’s pause a moment.  Doesn’t that go against the grain?  Aren’t you having one of those uncomfortable nail-on-chalkboard kind of moments right this second?  It’s a cultural thing.  AS project managers, we embrace complexity.  We take it as a challenge.  After all, if the project is too simple, they won’t need us.  No one wants to put on our resume, “Managed numerous really small, really simple, low-risk projects”.  No!  What we want is “Managed schedule for the space station” or “Managed 20 year project for Cure for Cancer”.  We are pulled to the complex project and that may be part of the problem.  It seems like heresy to even promote a simpler project but let’s suspend our disbelief for a moment and see if it makes sense.

First of all, almost every project can be broken into pieces.  In almost every project there is a kernel of an idea; a base functionality or a core construction.  Even in large complex projects, breaking the project into manageable pieces makes sense.  No one wants a schedule with 100,000 tasks.  But 20 projects with 5,000 each might just be manageable.

Even when you’re committed to a set list of functionality, releasing it in phases still makes sense.  Yes, I know there are times when that’s just not possible.  While it may be true, it’s the exception, rather than the rule.

“But wait,” you say, “if we do the whole project together, we’ll maintain the overall vision of the project.” 

Yes, that’s also true but that benefit comes with a host of risks.  Let’s take a look at some of the advantages and disadvantages of making projects smaller:

On the good side, a smaller project almost always has less risk.  It’s smaller, easier to understand, the finish line is that much closer than it would be in a smaller project and the whole team can drive towards the finish almost from the beginning.

A smaller project is also easier to schedule resources for.  The key personnel in any organization are going to be easier to lock up for a short period for a smaller project than they are for a longer more complex project.  Key resources (we’ve talked about them in here before) can’t be locked up in a single project for long.  They’re key for a reason.  So, the longer and more complex the project is, the more likely that you’ll only get partial attention from those kinds of folks.  The shorter the project is, the more likely the chance that you can get key people dedicated to it.

A smaller project gives back some return on investment sooner.  It’s true that the return will be lower than what you were hoping for from the entire vision of the bigger project, but it’s return coming in now rather than later and regardless of how you’re measuring that return, it’s always good to have some value coming back into the organization.

Finally a smaller project makes for faster successes and shorter, faster successes breed their own energy.  The longer and more complex a project is, the more likely it is to suck the energy right out of a team.


Ok, it’s not all grins and giggles.  There are a few down sides to making your project smaller. First of all, there’s a significant risk that the initial vision for the project will never be realized. Often what happens is the 80/20 rule takes hold with a vengeance.  The first 80% of the value gets delivered with 20% of the effort.  The last 20% of the value takes another 80% of effort.  So the problem becomes keeping the attention of management or the client when you’ve gotten the first 20% done.  By the same token, going for funding piecemeal makes a significant risk that you’ll get funding for the early parts of the project but not the later parts. 

Next, there’s a chance that we lose cohesion from the original vision.  With the project now broken up into smaller pieces, it’s possible that the original idea will be lost as we deal with each tree rather than the forest.

If we think of taking an initial vision and breaking it into distinct smaller projects, one of the risks is that it ultimately costs more.  While I think this is possible, you’ve got to temper the chance of this happening with the benefit of getting return on investment along the way with the completion of each smaller project that’s part of the whole.


So how do I do it?
 Ok, so there are some drawbacks and some advantages to making smaller projects out of your larger projects.  If you’ve decided you like the idea how do you do it?

Start with identifying the kernel of the idea within the larger project.   If you can identify some kernel of functionality or core principles see if those can be crafted into a base project from which other parts of the project could evolve.

If you’re looking at technology, then phasing in functionality over time can be another way to articulate the various pieces of a larger vision.

We look at projects to see whether we can divide up their functionality by geography, functionality, people or source of funding.  If you stop and look at the whole, there’s almost always a way to break it into pieces.  Then you’ve got to decide if you absolutely need to maintain the original vision which you can do in a separate piece on its own.  Call it the integration or supra-project if you like.

We talk about this concept in project management all the time when we train new project managers.  “Break the project into smaller and smaller components until you’ve got something you can manage,” we tell people.  Keep this in mind as you face the temptation of larger and larger projects.