I’m a child of the 60s. Born in 1958, I was 8 years old when the original Batman TV series came on the air in 1966 and only 10 when it wound up in 1968. It lasted a 120 episodes but the impression it made lasts to this day.

In the world of Adam West and Burt Ward who played Batman and Robin, there was a ‘bat’ solution to everything. No matter what the problem, Batman would have the solution. The Batmobile, Batboat, Batplane and Batcave all had their place. And, if you were someone who needed help no matter how difficult, how could you reach Batman? Well, with the Batphone of course! Pick up the Batphone and help would be on the way.

I’m nostalgic but reminiscing about a 1960’s series really isn’t my point today. It’s over 40 years since we were introduced to the red Batphone but we’ve got many clients who would dearly love to get their hands on one. I know I get calls on a regular basis from people hoping that I’m the person who could answer the Batphone and deliver them the help they want.

In the world of enterprise project management systems, a Batphone would be a wonderful thing to have. God knows, I wouldn’t mind the number myself from time to time. The problem is, enterprise project management solutions have always sounded easier to deliver than they are. There are a number of reasons for that.

Firstly, enterprise software of all kinds is now dependent on a “stack” of technology. They require a database and a database server, an application and an application server, there must be middleware, security and identification systems, middleware communications, the operating systems, a web server, client browser or other software and operating systems, firewall servers and probably email servers. Each and ever one of these elements should, you’d think, be designed to work with the other, but in fact, all those elements have probably been created with multiple purposes in mind. In fact, getting them all to work together is challenging enough but we also have a myriad combination of hardware and network issues. Oh, and we haven’t mentioned international versions and “localization” complexities.

That’s just the building blocks of the modern enterprise system. There’s a massive second element and that’s configuration. There are resource, rate, task and project tables, system options, report parameters, customizable fields, algorithm options, calendars, and ancillary files such as WBS’s, OBS’s and other categorizing tables to populate. Each of these can have an effect on what your enterprise system can do for you. How should you be organizing the system to generate the effects you desire? For most large epm systems there is a manual of course and then for many there are 3^rd party books and resources that can help with each element of the system.

The third and more significant challenge is to decide what you want to accomplish with your epm system. To determine the functionality to use in your epm system, you’ve got to spend some time thinking about how you’d like to manage your projects and your portfolio of projects. You’ll need to think about how to do preliminary schedules, determine the metrics for valuable vs. non-valuable projects, resource capacity planning, resource allocation, resource conflict management, project tracking, management intervention, costing, estimating, variance reporting and more. To do this you’ll need some knowledge of what your epm system is capable of and a lot of knowledge about how to manage projects.

There’s a workflow challenge to be managed too. Where will the data come from that will power this system? How will the data be gathered in such a way that the benefits of the epm system aren’t outweighed by the work required to feed it with data.

Did I mention training? Not ever project management user is created equal. You’ll need a skills inventory and a plan for ensure the people who need to do certain things with the epm system have the skills to do so.

Oh, what about changes? When any employee changes roles, you’ve got a training challenge and whenever there’s a new version of your epm software (as happens regularly) each of the elements above needs to be thought of again.

Is it any wonder we’d all love a Batphone?

For those of you who remember Batman, you know that he never charged for his services and, no matter how clever or diabolical the villain, Batman was always able to vanquish him within the 30 minutes available to him.

I must get all the calls from people who remember that part of the show. On a regular basis a call comes in for someone who thought that getting their epm system up and running would be a simple affair that the lowliest intern in their office could get underway perhaps with an hour or two of assistance from an internal IT person.

When that fails, there’s usually a second attempt; this time with someone more senior who’s given a couple of weeks to achieve victory.

That too has little hope of success and by week 8 or 26 or 52, often the organization regroups and somewhere in there I’ll often get the call. It’s terribly upsetting to most people when I tell them that their simple upgrade may be several weeks of work or that that simple “reinstallation” they want to do is senseless if they don’t decide first what they want to accomplish with the epm product they’ve already purchased.

On a semi-regular basis, I have someone on the phone who describes to me how long it should take for me to fix their problem. They, of course, don’t have any clue how to fix it or they’d have done it already. But, they also know with a certainty how my personnel should fix it and how long it’ll take (usually an hour or two). We have little choice but to decline such calls.

Another regular call is someone who has a big problem but describes it as a solution. “I need you to come and create a proper report,” they’ll say. “What do you want to have in it?” I’ll ask. They won’t know. I always ask the client to describe the business problem and offer to help describe a solution to that but it’s harder to get people to think that way than you’d think.

It’s no surprise perhaps that there is more and more movement towards hosted epm solutions. I know the IT industry expects that enterprise solutions of all kinds will move this way to avoid at least the technological “stack” challenge and let clients focus their attention on the business and configuration aspects of the system.

People who deploy enterprise project management need to take into account the complexity of the business and technical challenge because there’s no Batphone really.

It’s a shame too cause I’d be using it all the time.

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.

I tend to talk often in this column about “Enterprise” Project Management (EPM) Software.  It’s a hot topic these days because so many organizations want to get their project management personnel to coordinate their actions and management often feels at the effect of a lack of consolidated project management reports.  Organizations which do projects have an interest in such topics regardless of their size.  So it’s perhaps worthwhile to take a moment and examine what project management software vendors mean by “the enterprise”

If we think of the spectrum of project management systems, it’s pretty easy to identify the opposite ends of the spectrum. 

At one end we have the individual project manager.  He or she is responsible for the projects which they impact directly or for which they provide schedule and other project analysis and reporting.  In some organizations, there is only one project manager who only has a few projects to manage.  In such a situation, this project manager wears all the hats.  They do schedules, estimates, cost control, project tracking and project documentation.

With all the different roles such individuals play, it’s not surprising to find that they are most likely to have their own box of tools to get through their day.  In the project management software realm, the most common two tools are Microsoft Excel or Microsoft Project.  According to some estimates, there are about 35 million project managers using Excel as their primary project management tool and another 20 million using Microsoft Project.  There is a plethora of other tools to be found that target this market from freeware to open source to tools of all descriptions.  So, it’s fair to say that this part of the market is very well served by the project management software industry.

At the opposite end of the spectrum we have the ‘large enterprise’.  The precise definition of such organizations is different from one project management software to another but suffice it to say that the big vendors think ‘big’ when they use the word ‘enterprise’.  This typically means somewhere above 2000 employees and up to the largest organizations in the world of several hundred thousand employees.

When there are thousands of licenses of something to be sold, all kinds of large project management software vendors line up to try to get a piece of the action.  There are several categories of vendor who focus on large enterprise project management solutions.  In the ERP/Finance world we have the big players, SAP and Oracle who have finance-oriented solutions with project management and resource management modules.  In the specialist camp we have the omnipresent Microsoft with a collection of tools referred to as the Microsft EPM Solution along with Primavera (now an Oracle company), Clarity from Computer Associates and Planview.

These large scale tools really need to be thought of as more of a building platform than a closed set of functionality.  All of them arrive at the client’s door with tremendous potential and tremendous flexibility but little in the way of plug-and-play in the manner we think of the individual project management tools.

So far so good. 

But, there is an incredible number of companies in between these two huge markets.  The ‘mid-market’ is rather under-serviced and simultaneously rather over-promised. 

Where the ends of the project management software spectrum at the individual and enterprise levels are served by a relatively small number of vendors and products, in the mid-market, there are hundreds if not thousands of possible options.

The market is characterized by demands that the implementation of organizational project management be as fast and inexpensive as the individual end of the spectrum but deliver the complex functionality and integration from the enterprise end of the spectrum.  This is obviously not possible.  The notion of ‘easy-to-use enterprise project management software’ is a fantasy.  The concepts themselves aren’t easy and the culture change; the change-management aspect of the implementation can be terribly challenging.   I’ve talked about these challenges in here before.

So what do you do if you’re in this no-man’s land of organizational size – let’s say between 50 and 200 employees?

There are probably a hundred different paths you can take.  First, just as it is with all organizational solutions, it’s very important to start by defining the problem.  What are the business problems you’re trying to resolve?  If the problem is reporting based, perhaps you can overcome this by having a centralized super-user who will generate, analyze and publish reports.  If the problem is resource oriented, perhaps you can look at combining tools to have a small central group of project managers distribute reporting information to all the other personnel.  If the problem is team communications and collaboration, then perhaps one of the many collaboration tools can overcome this challenge without having to consider a large implementation of specialized project software.

If I was faced with such a challenge, here’s what my most likely response would be:

People
First I’d look to create a tiny (maybe just one person) Project Management Office.  If there’s to be any coordination of efforts in the project management realm, it won’t happen by accident.  There has to be a central rallying point for the initiative and for future evolution of the structure.  Next, I’d look to create a very small cadre of experienced project managers and I’d dedicate them to the Project Manager role.  This is one of the things that’s so rarely done and most executives don’t realize the cost due to lack of efficiency of not having specialist personnel in these roles. 

Tools
I’d almost certainly leverage the low cost and quick-to-deploy individual project management tools but I’d look to extend them with some add-ons.   If my challenge was team communications, I might consider using a collaboration tool, but I might also just look to see what I need the team to communicate about and see if there were tools that lent themselves to the process that could be managed centrally.  If my challenge was reporting and viewing of project data, I’d consider one of the low-cost viewers for Microsoft Project or Primavera or a report writing tool.

Here are some add-on or mid-market targeted tools I might consider:

EasyTaskSync (www.easytasksync.com)
This tool moves data back and forth from Microsoft Project to Outlook, allowing a single project manager to get a lot of personnel involved in the project through a tool that is likely to be on everyone’s desktop.

DecisionEdge (www.decisionedge.com)
This report-writer produces a range of great looking reports from data contained in Microsoft Project or Primavera.  The resulting reports can be made available over the web or in printed form.

EPMLive (www.projectpublisher.com)
EPMLive hosts Project Server with a pre-set list of functions. Views, User Defined Fields, structures are set up in an attempt to make the big Project Server system a little easier to swallow.

Daptiv (www.daptiv.com)
While we’re talking about hosted systems, another option would be Daptiv who has portfolio management, scheduling and resource management in a web-based structure.

Microsoft Project Viewers
SteelRay Project Viewer (www.steelray.com)
Afinion Project Viewer (www.afinion.com)
Seavus Project Viewer (www.seavusprojectviewer.com)
Houstatonic Project Viewer (www.projectviewercentral.com)
Live Project Viewer (www.kadonk.com)
Each of these claim to be the top Microsoft Project Viewer on the market and I’m sure there are a hundred more.

When you’re in the massive mid-market for organizational project management software, there’s unfortunately no clear leader or small number of tools which dominate the market.  You’ll need to be a little more crafty and put in a little more homework before you land on just the right combination of tools to get to the particular solution that’s appropriate to you.

Remember the basics: Articulate the particular business problem you want to resolve with these project management tools and make sure the vendors you talk to are ready to empower this thinking at the appropriate level for what you require.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Are you baselining?  I know, it sounds like some drug-related crime, doesn’t it?  It’s actually one of the most fundamental aspects of modern project management and a stunning percentage of project managers don’t do it.  So this month I thought I’d dedicate the column to the elusive art of baselining.

So, what’s a baseline?

First of all, what is a baseline?  Everyone agrees it’s a snapshot of your project which is frozen now for use as a comparison later but consensus ends there.  A snapshot… of what?   What does the snapshot contain?  If it’s changeable is it really a baseline?  All sorts of questions arise when we introduce the concept.

The most common kind of baseline is for the project schedule.  Most project management tools include the ability to save the start and finish dates of each task into something called a baseline.  Ok, we’re just into the schedule so far, but which start and finish dates are we talking about?  The early dates? The late dates? The resource-scheduled dates? The constraint dates? The critical-chain late dates? Target dates that have been contractually agreed upon?

It’s enough to give you a headache, isn’t it.

The short answer is, it depends on how you want to manage your project.  The most common dates that would be saved in a scheduling tool would be the early dates.  But, if you’re doing resource-constrained schedules, then the resource-scheduled dates makes the most sense.  If you need to do reporting to a client, then a target date will be more attractive.  In short, you’ve got to decide before you start what you’d like to use as the basis for comparison. 

Now, we’ve just talked about baselining the schedule but there are some organizations that will also baseline the costs.  They will do planned vs. actual expeditures.  Or, you can baseline the cash flow as you might for an Earned Value project in the defence sector or you can baseline the resource assignments vs. the resource usage showing how close your original plan was in the way you consumed your resources or you can baseline the risk for each task.

The point of all of this is to have something against which you can compare later.

Can you change it?
People who just get started with baselines often think of them as an inviolate set of records and that’s only partly accurate.  What happens if a new task is added to the project?  Should it be baselined?  The obvious answer is, of “course” but here’s a harder question: What if adding that new task means that other tasks will now not be able to meet their original baseline?  Should you be allowed to change the baseline on those tasks in order to avoid a task variance that’s sure to ensue when you only think about the original work?

It is very common in many project environments to have an authorized change of scope in mid-project.  Even when the project is for an external client it isn’t uncommon for a client to ask for the project to change.  So, what do we do with the baseline not only for the new tasks but also for the tasks which may be affected by the change?  Most project management tools allow you to create a baseline only for certain tasks or to track multiple baselines.

If you are‘re-baselining’ in mid-project, then there are a couple of principles to think about.  First, what will you do with existing tasks that have actual results?  Will you use the actual as the baseline or keep the original baseline to compare later?  Next, you want to be sure that the original, original baseline is maintained for comparison later.  No matter how many ‘approved’ changes there are, it’s certain that one day down the road, someone will want to compare the completed plan with the original intent.  By the same token you want to be able to identify each authorized change in scope separately.  When management asks ‘what was the original plan of just the new scope?’ you want to be able to answer. 

Finally, the process by which someone gets to change or create a new baseline should be understood by everyone.  I can still remember one of my first clients who explained their re-baselining process.  “Whenever we’re more than 10% variant, we rebaseline,” the project manager explained to my incredulous ears.  Sure enough, while I was working at this company, senior management from the head office asked to see the current plan for a 4-year old project’s “original-original” baseline.  The original plan had been $400,000 and the current plan was well over $4,000,000.  It had creeped up a few thousand at a time every couple of months until it reached the current staggering number.  The project was cancelled a day or two later.

Doesn’t everyone already do this?
There is a surprisingly high percentage of users who never baseline their project.  They make a plan and then adjust and update the plan according to changing conditions.  What they can’t do is compare the current plan to the original.  There are many project management environments where the idea of comparing against the original plan is very unattractive because the corporate culture is to not be managed at all.  Now, no one admits to that being the reason.  Instead you get something like “We’re a design-build company so we are always changing the scope” or “The project moves too quickly to stop and take a baseline” or “It takes too much work to keep up with the variances in the project and it’s just a distraction”.   Whatever the reason, without a baseline, these organizations are unable to compare their original project plan with how it ultimately turned out and so measuring project performance is close to impossible.  These organizations will often have a recurring problem with projects enduring scope creep and missed deadlines and budgets.

Ok, I’ve got a baseline… now what?
The whole point of doing baselines is to compare them against the current plan later.  Regardless of whether you’re comparing dates or costs or resources, what you should start with before you even record the baseline is an idea of what kind of report you’ll need on a regular basis to identify the variances and, much more important what you’ll do when one happens.  The best practice is to define a series of thresholds and some kind of process that is triggered when the threshold is exceeded.  It can be as simple as a project review by a senior manager but some kind of process should happen when the number is exceeded.

Let’s wrap up
The attractive displays that most project management tool vendors will show you are almost always based on some kind of baseline being established and that’s no accident.  The variance reports that show the current plan vs. the baseline are exactly what both senior management and project managers look for when they want to intervene and make a difference.  A few months ago I met with a company who regularly do a very repetitive project.  The project is a little different every time but the basic elements are all the same and so they’ve gotten used to doing it the same every time.  “Where is the baseline to compare against the last few times you’ve done the project?” I asked.  They all looked at each other.  There was no such data.  The current plan had no baseline.  “But it always takes the same amount of time,” grumbled one of the managers.  “Why bother comparing?”

“Because using a baseline gives us something to target; something to push against,” I replied.  “And, pushing against the target is the best way for us to be as efficient as possible.”

After all, isn’t that what project management is all about?

When project management software is presented by their vendors these days, we tend to hear the ‘core’ subjects: critical scheduling, portfolio analysis, resource capacity planning, risk analysis, inter-project reporting and so on.  If you’ve not been in one of these demonstrations before, you’re missing something.  They’re a sight to behold.  The software sits up on its hind legs, barks and then runs out to get you a cappuccino.  Ok, maybe not quite.  But these enterprise project management system presentations are pretty impressive.

I’ve been in the background of preparing such demonstrations and I can tell you that an enormous amount of work goes into them.  It’s easily understood.  The software vendor doesn’t want to show what the software will look like when it’s delivered, they want to show what it will look like after it’s been adopted, used, updated, personalized and is delivering the great results the client is hoping for.  To be fair, that’s what the prospective client wants to see too.  They want to see a finished product looking like it would if they had completed their implementation.

To prepare such demonstrations an entire fictitious organization must be created.  It’s not enough just to imagine some tasks because, just like a real organization, all kinds of data must relate to all kinds of other data and this means assembling a story.  Once the story is written, the data must be created to match it and then installation and configuration of the software has to happen.  There are also reports, views, filters, and such to be created so that the prospective clients can see how everything fits together.

I bring all this up because what often happens during these presentations is that the prospective client gets very excited about the delivery of a solution that will solve all their problems; the “silver bullet” solution (of Lone Ranger fame) which will always reach its target no matter how far or how small.

The truth is, some of these answers are hard to come by.  I’ve found over the years that the most requested solution by organizations seeking an enterprise project management solution is “Resource Capacity Planning”.  This is unfortunately the first thing (and sometimes the only thing) they ask for and it’s almost always the last thing I can deliver.  It’s not that I’m being difficult, but creating a resource capacity planning solution implies a lot of underlying assumptions to be resolved.  First, you must have 100% of the resource availability. Next, you must have 100% of the resource load which must be organized by task.  These two items are just the collection of the base data required for a resource capacity analysis.  These items alone are so daunting for most organizations that just overcoming the cultural challenges required to get all the data will overwhelm the project.  If we overcome these, we’re still not done.  We need a prioritization process that identifies which work should get first access to restricted resources.  We need a process that will have everyone update the resource availability and requirements on a normalized basis.  We need analysis and reports that make sense of what may be an enormous volume of data.  We need metrics to determine what the reports mean and finally an action plan which fits into our process to take the appropriate action where the metrics indicate.

Whew!  I know… It’s daunting, isn’t it?

In a mid-sized organization, delivering this kind of EPM solution can take up to two years or more.  Some results can be produced much faster but there are some much more interesting aspects to software deployment in the enterprise project management context when we look outside of the core project scheduling functionality. 

First of all, there is a huge range of online training in soft skills.  You can take courses in leadership, negotiation, assertiveness, communications and dozens of other subjects.

If we take a look at communications for a moment, the whole domain of online collaboration is a huge area of benefit.  You can use Microsoft’s Windows SharePoint Services to create online portals for project work.  Windows SharePoint Services is included as part of Windows Server and includes the ability to create event lists, lists of contacts, tasks, file sharing, document management and more.  If you’d rather not install software, you can look at services like Google Groups.  On Google, you can create a private group for your project team and store up to 100MB of files, start discussions, make announcements and share information no matter where people log in from.  You can tie Google Groups with Google Documents and Google Calendars to share a wider range of information.  If the group is small, the functionality may suit you rather well and you can’t beat the price.  It’s free.

If you’d prefer to do something a little more involve, there are a number of content management systems such as PostNuke, Joomla, Drupal, DotNetNuke, and DotProject.net.  These sytems can be installed or hosted almost anywhere and provide a rich environment for creating a communication and collaboration environment.  Data of almost any kind can be stored and, when it’s your own system, you can tweak it and customize it and even add on to it to your heart’s content.

For some the key is managing documents and there are a number of solutions for this challenge as well.  If the requirement is for a small team, both Google Documents and Google Groups offer a lot of functionality for no cost.  If you’re keen to go a little deeper and host the solution locally, you can do basic document management with Windows SharePoint Services.

There are also a number of free document management systems (dms) available for download which include a much richer level of document management functionality.  Examples would be OpenDocMan, Epiware (who also includes tasks and a Gantt chart!) or DocumentManagementSystem (on www.SourceForge.net) .

If what you really need is a centralized location where all your research can be compiled and added to and updated by different team members, then creating your own Wiki is the way to go.  Made famous by the Wikipedia folks, you can install your own Wiki software.  There are dozens of free versions.  Just search for “Free Wiki Software” to see the most current.

These aspects of your project management environment may seem like “ancillary” functionality but make no mistake about the potential for these aspects to deliver a tremendous impact.  Implementing an effective communications process where there was none can seem like the difference between night and day. Introducing a collaborative commitment tracking system can deliver instant focus to a team that might not be co-located. 

One of the most powerful things about these aspects of the enterprise project management environment is that it can be very, very fast to deploy compared, say, to resource capacity planning.

We’ve talked a range of alternative software systems for working on aspects of your project management environment that are outside the core scheduling capabilities but of course much of this kind of functionality can also be found woven within the major enterprise project management systems on the market today.  If you’re evaluating whether to use these commercial systems to work on these other aspects of the project management environment, then make sure the benefits of these areas can be delivered without first getting all the core scheduling organized as part of the same exercise.  Some EPM systems are schedule-centric.  They were designed around the notion that the schedule would be the key element around which all other data and all other functionality would be tied.  No centralized scheduling for these systems means no centralized anything.

There are many paths to delivering effectiveness in your project management environment.  You don’t have to settle for the most obvious.  With so many different tools and services available immediately, it is within your power to make an impact in a very short amount of time.

“How do you pronounce ‘EPM’?” I asked one of our consultants recently.

 “Enterprise Project Management?” he replied.

 “No,” I said. “You pronounce it P-M-O.”

 It has become more and more common in recent years for us to have to deliver this message to prospective clients considering the implementation of an Enterprise Project Management System.  It’s no wonder that most consulting firms who deliver EPM system deployment assistance also manage extensive requests to implement Project Management Offices.  “Do you have a PMO?” has become one of our most immediate watershed questions.  Those who answer no are usually not in a position to take immediate advantage of an EPM system.  Those who answer yes often have established some of the basic pre-requisites that anyone should be looking for before putting down money for their favourite EPM Software.  Here are a few of the key pre-requisites we look for when a client calls and asks us to implement an EPM System.

Do you have a PMO?
I might as well start here given it’s how I started the column.  The existence of a project management office is almost essential to a successful EPM deployment and here’s why.  Every EPM system essentially brings many project managers and project resources together into a centralized project management environment.  All their data will now be centrally stored.  The data may be centrally calculated and analyzed.  The benefits being sought by those who buy EPM systems are typically centralized benefits; things like resource capacity planning and inter-project impact reports and organization-wide project variance analysis and corporate reporting.  All of these things can be wonderful, but they are imply some level of coordinated action.  The data must be saved by everyone in the same period of time.  The data must be analyzed in the same manner.  The data from project 1 must be able to integrate at some level with the data from project 2 and so on.  This simply doesn’t happen by accident and while EPM tools have the capacity for coordinated action, they can’t make people behave differently. 

What each EPM system absolutely needs is a centralized place where standards can be maintained and where the enterprise project management system can be maintained.  It requires someone who will be looking for others to comply with the central system and will ensure that data that is received is both complete and acceptable to the standards that have been set.  Imagine if there was no common understanding of how to define resource assignments or even how to name resources.  Some project managers would enter them as skills, others as individuals, others as departments.  It would be chaos.  Imagine if some project managers updated their projects every week, others every month and still others only at the project’s outset and completion; you’d never know when you could produce an accurate organization-wide report. 

A flag-bearer for standards
While we’re talking about standards, there has to be someone central who will be their champion.  Even if these practices and procedures somehow got produced from the end users, who will be their keeper?  Some will say “We’ll all keep them but that leaves no one accountable to ensure the practices are being followed.  Standards are essential to an EPM system even if that system is completely manual.  Some people get concerned that this centralized person will have too much authority but this too can be managed within the standards.  The notion that a group of people can be accountable is silly.  People will do whatever they think is best but creation of standards doesn’t happen randomly.  This can only be done by someone central.  Moreoever, you’re going to have to think about the future.  Even one standards and practices have been adopted there will be changes.  When a change must be made, who will create it, update it, get it accepted by everyone and then ensure that it is written into corporate policy?  Again, this doesn’t happen from a random end user, it requires someone whose role it is to support those standards.

Project Management Practices and Procedures
One of the most common things we encounter when we’re called by a prospective client is a lack of centralized process.  When we ask to see a list of accepted practices and procedures for project management, we usually get a blank stare.  It’s not enough to have a PMO and a centralized Standard Bearer for the process, you’ve actually got to bite the bullet and create and agree on those standards.  Our usual recommendation is to start with the most minimal number of procedures possible and then let the list expand over time.  Some clients will try to create the ultimate über-list of practices and procedures and end up with a 700 page tome that no one will ever read because it’s too confronting.  Starting small but getting a high degree of consensus is by far the preferable plan.

One way or the other though, you’re going to have to agree on a few basics:

• First, how you’ll name things.  Naming conventions for projects, tasks and resources is absolutely essential
• That you’ll store your projects centrally in whatever tool or repository you’ve chosen.  A firm agreement has to be made on what data must be saved and what data need not be.  Without this agreement and someone who will monitor compliance, your EPM system is going nowhere fast.
• Frequency of updates.  It makes no sense to have some data updated every week and some updated every year.  Make an agreement on what the frequency should be for different kinds of data.

Support for the Technical Infrastructure
I can’t possibly list all the weird and wonderful infrastructure problems we’ve encountered at client sites.  We’ve been called in to help with a centralized server-based project management system only to find that it’s not installed on a server at all, it’s been squeezed onto someone’s laptop and every time they reboot, the system becomes unavailable to everyone.  We’ve seen server-based systems that aren’t listed in the IT department’s list of secure servers because some department installed them on their own.  The installation went fine, but the server will never be available because the IT department allows only authorized servers through the firewall.

Whatever centralized tool you select, you’re going to have to make sure that it is supported by the people in your organization who do such things.  Server-based project management tools are not like tools from 10 or 15 years ago.  They depend on a ‘stack’ of technology.  A database server, a web server, a firewall, an internet connection, a browser, the client operating system, an identity or security server and more.  When an update to your EPM system arrives, it may well require updates to all kinds of elements of the ‘stack’.  Someone needs to be accountable that the system and all the technology that it depends on is maintained and monitored.  There will be regular maintenance and monitoring required and that won’t happen with some random user.  It requires someone who will report back to the PMO that the system is working properly or that maintenance effort is required.

Implementing an Enterprise Project Management environment can lead an organization to a tremendous increase in efficiency.  When the economy is challenging, being more efficient is in high demand.  But, not having the pre-requisites ready or not considering what might be required to make an EPM environment successful can make an efficiency project very costly both in time and money.  Ask someone with experience to make sure that you’ve prepared properly before embarking on your EPM deployment.

It happens to me all the time.  The mail arrives and in it is an RFP.  They’re three dreaded letters around my office and I’ll tell you why.  The “Request for Proposal” is a construct of purchasing departments designed to compare vendors with similar products to sell.  The RFP is supposed to list in exacting detail exactly what kind of proposal the client requires and the respondents are expected to prepare their proposal and give the best possible price to the client.  The client evaluates all the proposals together and then knows who can give the best possible solution to them.

It works great when the client is looking to buy army boots or kitchen knives or storage containers.  It’s virtually useless when used to purchase an enterprise system and here’s why:

First of all, let’s take a look at how we assemble the RFP.  The beginning and end of the document are boilerplate.  They list the process of how to respond and the legal terms of what responding may mean and what you must or must not agree to.  In fact, most of this is not that useful, since if you are the winning bidder, you’ll need to go a whole new round of terms negotiations with the contracts people but either way, this is not our big concern.  No, it’s the bit in the middle we want to talk about.

In the middle we’re supposed to have a list of those requirements in ‘exacting detail’.  The client must assemble the various parties involved to see what they would like in our new enterprise system.  Perhaps a committee is convened or a series of focused workshops to work through all the implications of each requirement.  Perhaps there is a long period devoted to developing the business requirements that will resolve to system features.

 If only…

In fact, what’s more likely is the project manager assigned to this project will have a short meeting or perhaps two during which he or she will make a request that the participants represent their departments by listing all the features that are important to them.  Each person goes back to their group and sends an email saying “This is your only chance to have any impact on what we’ll need in the new enterprise system.  Speak up now or forever hold your peace.”  The departments respond in an uneven fashion.  Some department members give the request serious consideration and submit a long list of things.  Others give only a perfunctory response.

The project manager now assembles these items into a spreadsheet and adds a few columns: “Priority”, “Comment”, “Included”.  The end result looks like this:

Gosh, it looks good so far, doesn’t it?  The spreadsheet fills out quickly.  For the more organized clients, on the internal copy (the one not sent to the RFP respondents) is a column called “Weighted”.  This is where the relevant score weighting for each item is entered.

 The project manager now merges line after line, categorizing them perhaps to make sure there are no big feature holes.  In the end, what is received is a remarkable list of features that looks just like every EPM system brochure on the market today.

Now, the vendors get this list and scratch their heads.  God knows, I’ve done it plenty.  They look at the list of features listed and try to make sense of why some features are listed 2, 3 even 4 times but each worded a little differently.  They try to reconcile some features which seem diametrically opposed to each other.  They ask questions for features which seem deliberately vague like “The system must automatically transfer data with our internal LIMS environment”.  Invariably the acronym LIMS is not explained and the details of what the expectation may be are not available.

But there is a profound problem with this process.  Have you spotted it yet?  The RFP is describing the solution not the problem.  It’s a massive disconnect and no one ever talks about it.  The purchaser or the project manager assembles a list of every feature all his or her users can come up with and presents that list to the vendors but what is not at all clear is whether the delivery of those features will make the lives of anyone at the client company any better.

So, what happens?  Vendors go through an exercise of preparing a hundred-page or sometimes a multi-hundred page response.  The client receives several of these.   The selection committee reviews them all.  They all say the same thing: “We can deliver every feature you’ve described.”  Sometimes vendors tick off every line item with a “yes”, even the ones that don’t make sense or are in complete conflict with other line items.

The hapless readers must wade through these documents trying to determine which vendor makes sense.  The weighting scheme tells them what features are more or less important but the scores after everything is done are very close.  The biggest impact on scores?  The neatness of the work.  I know, it sounds childish but ask around and see if it’s not true.  The vendor with the most colourful, neatest, easiest to read response always scores well.

Now a short list is assembled and a couple of vendors are invited to do demonstrations.  Typically the meetings are a couple of hours or less.  In the most frustrating cases, the client asks that the demonstration look exactly like what their system will look like after it’s purchased, configured, populated with data, customized and enhanced.  This obviously can’t be presented.  But, the meeting is important because it’s the first time the vendor gets to meet the end users and ask “What on earth is it you need to accomplish?  What are you suffering from?  What is the problem?”

In the end, purchasing decisions are often made one level above the selection committee anyway.  An executive makes that decision not based on a requirement analysis but on the recommendation of a trusted advisor, or a friend or colleague who once bought a similar system.  Will it work?  Sometimes and sometimes not but it’s a certainty the system purchased was not done based on what the company is struggling with.

“But that’s the best purchasing process we can come up with,” I’m sometimes told.

I truly doubt it. 

If you’re considering moving to a new EPM system in the New Year, I’ve got a couple of recommendations for your purchasing process.

First, start with the problem, not a description of what you think the solution should be.  List the business challenges that you are finding it difficult to overcome.  They can be articulated in terms of business decisions that you find difficult to make or business process inefficiencies which you wish to improve.  Saying “the system must help us decide to increase or decrease our future resource commitments with sub-contractors but delivering resource capacity planning such that we can see a projection for the next 90 days of resource requirements and resource capacity.” is incredibly more powerful than saying “The system must have resource capacity planning reports.”

A vendor who understands the business challenges will feel more latitude to craft a response which may be more creative and, even better, in ways that you’ve never imagined.

Next, put less attention on the vendor demonstrations and more on vendor references.  Probably the most valuable thing you can do during this process is arrange to visit the sites of other clients of the vendor.  A vendor salesperson demonstration will always look sharp but a real client will almost always be honest enough to explain the parts of the deployment that went great and those which were more challenging.

Finally, make sure that management gets on board with this process early and stays involved.  There’s little more debilitating than having a selection group work at something like this for months only to find out that none of their work will be considered when someone from senior management makes the final decision.

Happy buying!

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

Surveys
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!

There’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:

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

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