Author: Chris Vandersluis

The Project Communication Plan

Written by Chris Vandersluis on September 23, 2009. Posted in Articles. 4 Comments on The Project Communication Plan

At one time the notion of a communication plan in project management consisted of whatever the project manager was willing to share with you. Back in the days when project management was synonymous with project scheduling and the primary industries that used project management were construction and defense, and heavy industry, the project manager’s word was law and whatever he (or she) decided to report, that was it. Output from the scheduling department might be a simple list of key target dates or perhaps a summary bar chart written by a draftsman and annotated all over the page.

Of course those were also the days before cell phones, email, faxes and the Internet.

Project management in today’s world is expected to be as extensive as possible, and technology can go a long way towards making the project manager’s life a whole lot easier.

For new project managers, they might not have even thought of doing a communication plan but some preparation before your project gets going can save you enormous suffering later.

Start by identifying who will need to be communicated with. Project stakeholders is an easy way of saying everyone who has some interest in the project but these might include: The executive sponsor, the client, the project management team, the leaders of resources included in the project, sub-contractors, prime contractors, the end users and, of course, the project team.

Next think about what you might need to communicate with these people about. I tend to divide this by: period, by incident, by key milestone. For example, you might need to talk to your team about your weekly project meeting. You might also set up informing the executive sponsor about project progress at a summary level on a monthly basis. Those are per-period type of communications. You might commit to updating the client and a steering committee about status at a stage-gate point, such as at the end of a phase or you might do a team project review at the end of each major deliverable. Those are per milestone communications. Finally, you might commit to communicate with the executive sponsor or the client if the project exceeds threshold levels such as more than 10% late or more than 15% over or under budget. Those are per-incident communications.

This can be done on a simple grid on a spreadsheet. There are plenty of examples on the Internet.

If you’re thinking that’s already a lot of communicating, fear not. Technology can now play a hand to make a huge difference in executing that communication.

Email of course is a great way to get information from one person to another and also provides some audit of communications delivered. These days many business people are reading their emails from smart phones on their hip, so if the information is urgent or if it requires a rapid response, email is the obvious choice.

A lot of reporting however can be done through one-to-many communication tools. Setting up a Google Group takes a couple of minutes and provides a place to store documents and make short announcements, and even provide a place for people to update you with comments such as a review of a draft design document. Google is hardly the only service to provide such group setups but it’s free, comes with several gigabytes of storage and can be kept private by defining the group as by invitation only.

Keen to go a little further? Both Google and Microsoft offer Application areas that are either free or available at very low cost. They typically include a place to make lists of things, store documents and display calendars for the participants, to which they can subscribe. Users can usually also set up alerts for new information posted to either a Group or Application area which will then appear in their email.

In some environments, one tool that has become more and more popular is setting up a blog from a key team member such as the project manager or a key developer. The blog is closed typically, but it’s a great way for team members who might not be located nearby to keep up with short news about how the project is progressing from that person’s perspective, and even to comment on developments as they occur. Blogs can be set up in dozens of places but blogspot.com and wordpress.org are common and free destinations. Blogs can also be set-up internally with almost no technical effort at all.

When there is a lot of technical information that must be documented and the documenters will be a varied group, then creating a wiki is an excellent choice. Most of us have stopped by Wikipedia to look up information at one time or another. Wikis, however, aren’t restricted to that one site. The technology can be installed or used as a free service from dozens of locations. What makes a Wiki interesting is that a shell of subjects can be created by a central authority and then anyone with the appropriate rights can contribute to the actual content. Imagine, for example, that you’d like to create a document of best practices for the new application you’re writing. You create a private Wiki and put as headings the functional menu choices of the entire application. Now Beta Testers, Documenters, Developers and ultimately the end users and clients can contribute their thoughts to the Wiki and enrich the entire user community with practices, tips and techniques that have been learned. We’re doing something like this ourselves for our own product TimeControl right now.

When it comes to meetings most of us enjoy using video conferencing from people like GoTo Meeting, WebEx or others and sharing our PowerPoints while doing so. There are, however, some great technologies for making meetings more effective. Instead of a static one-to-many PowerPoint that everyone speaks to from their speakerphone, how about using a more dynamic online screen that includes the agenda, commitments that were made at the last meeting along with who made them, decisions that are taken at this meeting and documents that everyone can see at the same time. I know that the free version of Windows SharePoint Services that comes with Windows Server has a template exactly like this which can be activated when you create a “worksite” to a recurring calendar item. People’s jaws usually drop when I show off this free feature and they’ve had it available to them before I even arrived.

Having chosen whatever technology is appropriate for your organization, your communication plan can be rounded out by creating some templates for regular communication in advance, so you don’t need to invent it on the fly when under the pressure of a project that’s underway.

Whatever your communication plan and the tools you’re going to use to deliver it, set expectations of the stakeholders before you start. If people know and agree on a frequency of a certain kind of communication long in advance, it can save a tremendous amount of grief and misunderstanding later.

Don’t forget to leave your comments below

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected].

Workflow Wonders

Written by Chris Vandersluis on August 26, 2009. Posted in Articles. 8 Comments on Workflow Wonders

One of the big challenges with project management and project management systems has always been the entry of critical information. Project management information is so dependent on the context that getting it wrong is very easy. Think about it for a moment. We ask for a task description. But relatively few people have the skill and experience required to define a task description properly. We ask for a duration, but asking several people results in as many different durations as we have people. In the project management industry we’ve always responded to this by saying ‘more training’ and, to be sure, training makes a difference but we’re about to see a focus on project management software that will try to do away with this challenge.

It’s all to do with the term Workflow. Workflow refers to the concept of taking a process and organizing the sequencing of that process including conditional branches. This is very familiar to project management people as the thinking is just like the flow of a project. Workflow software however has become all the rage and it has the potential to make a profound difference in project management systems when linked with databases, lists and, in particular: forms.

Think of this scenario. A new project manager is assigned to create a new project. He goes to the corporate Intranet where he clicks on “Create a new project”. A form appears. He fills in the blanks. Depending on some entries he makes in the form, he might be asked for more information. He completes the form and submits it. Depending on other entries in the form, the approval process might be directed to one person or another.

This is the result of Workflow.

But wait, we’re not done! The workflow engine also sends an email to the person who approves his kind of project. The pending project is put on a list of potential projects in the portfolio management system. A portfolio manager is notified by the Workflow engine that a pending project has been added to their portfolio and asks them to intervene to give it a priority.

The manager approves the project. The portfolio manager sets the priority and as a result, resource scheduling determines the schedule. The Workflow engine wakes up to these responses and sends an email back to our newbie project manager letting him know that his project is approved and telling him when he’ll be getting staff to get it started.

Sound like science fiction? It’s not. The tools for doing this exist right now. Microsoft has been promoting the Windows Workflow Foundation (WWF and yes, I know that’s also the acronym for the World Wrestling Foundation) and how it links to their Infopath forms that are part of Microsoft Office SharePoint Server. Demonstrations that are now viewable of Microsoft Project Server lean heavily on this technology as a method of collecting and organizing data, and as a way of communicating with users in an unattended fashion. It doesn’t take a rocket scientist to see that this kind of workflow is a future marquis feature for Microsoft and that it is likely to figure strongly in future versions of Project Server.

Are we stuck with Microsoft, though, to do this kind of thing? Absolutely not! If you’ve already got SharePoint Server in house, then you’ve bought the technology already, so you might not want to look elsewhere, but there are numerous workflow solutions in the open-source community. You’ll find a range of possible solutions on SourceForge (www.sourceforge.net). For information on the WWF, do a search on any search engine of “SharePoint Workflow”.

We’ve not begun to scratch the surface of what’s possible with this kind of approach to collecting data. The beauty of it is the level of intelligence that can now be woven behind the scenes into the forms that are being filled out. Let’s take our new project example.

The form could ask our new project manager to complete a “Risk Assessment” form if the value of his project is over $10,000 or if the duration is more than 26 weeks or if the work is being done for the government. The form could insist that this Risk Assessment form be completed before he even tries to submit his request for project approval.

The form could decide to send the request to a supervisor for approval if its value is less than $10,000 and to a senior manager if it’s worth more.

The form could decide to immediately email the portfolio manager if the project is marked as “urgent” or if the executive sponsor is the CEO.

And so on and so on.

Notice anything here? I keep saying the “form could decide” but of course, forms don’t decide anything and therein likes the rub. Any of the workflow we’re discussing here has to be coded or programmed or defined in some way for the workflow engine to understand and that can be a challenge. In many of the project organizations I visit, the manual workflow process is ill- defined, not honoured or not defined at all. This kind of solution will demonstrate wonderfully and people will Ooooo! and Awwww! when they see it, but delivering the demo will take a lot more work. A lot more!

Just because the technology enables this kind of thing doesn’t mean that organizations are ready to do the homework required to adopt it. I’ve been involved over the years in numerous workflow design meetings. In order to establish just one workflow process successfully, you need to bring together everyone who intervenes in that process now, as well as those who are clients of the process (meaning they receive the product that comes out of the process) and the suppliers of the process (meaning they provide input that results in the product). You have to look at all the possible permutations. You have to look at where the data will come from, all the possible actions you want to come out of the form(s) and process based on possible answers to questions and then you need to document, train, test and document some more. Yes, the potential efficiency improvements might be huge but you shouldn’t trivialize the work involved in automating the workflow of a process even with great technology at your fingertips.

One of the other hidden pitfalls of workflow automation is the maintenance of this in-the-background-intelligence. What happens when the team that defined the workflow moves on to other things? Who will maintain the rules in the form and make sure they’re adapted to changing business conditions? How were these rules documented? Who maintains that documentation? And, so on.

No matter what, you’re going to hear a lot more about workflow automation in the year or two because it’s just too compelling a technology to ignore and for larger organizations, automating any process that is done many times can result in huge efficiency savings but, like all of these tools, be sure you know not just the benefits but also the total costs before you start your own implementation.

Don’t forget to leave your comments below

The Project’s a Disaster! Were You Prepared?

Written by Chris Vandersluis on July 29, 2009. Posted in Articles. 5 Comments on The Project’s a Disaster! Were You Prepared?

I’m well known for using my favorite project management quote which comes courtesy of Napoleon Bonaparte, “A battle plan lasts until contact with the enemy.” This is also true of project plans. It’s a good thing too for those of us in the project management industry. After all, if there were no challenges to projects being completed on time, on budget and as expected, we’d have no need for project managers.

It’s always surprising to me however, that given that project managers are in the business of overcoming project problems, so few of us actually prepare for them. Disaster planning and disaster recovery are becoming more and more of a science from a number of perspectives. Governments now often maintain emergency preparedness organizations. In most federal, regional and municipal governments, there is some expectation that sooner or later disaster will need to be dealt with and organizations have been set up to prepare for that time.

In the IT industry, disaster recovery is a well known aspect of an IT environment. Having just recovered from a major server crash myself in the last few weeks, I know that the more prepared we are for the inevitable hardware failure, the quicker we are to recover and the less time lost to the emergency.

However, when I look at the vast majority of project schedules, this same level of preparedness is rarely present. Schedules are most often planned with the most optimistic perspective and dire consequences if they are a day late or a dollar over budget. When I talk about contingency, risk assessment, fall-back plans or alternate project plans, I’m most often greeted with a blank look.

So, how does a project manager prepare for the inevitable project disaster?

Did You Plan for It?

Every project plan when examined critically has weak spots. Every one! The experienced project manager knows to look at those areas of the project more stringently than others. If you know that a key aspect of design is of higher risk than the rest of the project, then thinking about how you’ll adapt if that part of the project is delayed or derailed will make your life infinitely easier later. For each risk element of the plan, it’s worth keeping “what-if” notes. What if that part doesn’t arrive? What if that resource isn’t available? What if we need to move ahead without this part of the project complete? Risk assessment usually isn’t required for the entire project so spending more time on the obviously riskier areas almost always pays off later. “Plans are nothing. Planning is everything,” said Eisenhower after the D-Day invasion. If the project is very complex you can use Risk Analysis software such as @Risk to get a Monte Carlo simulation of what elements of the schedule are more at risk than others.

Did You See It Coming?

Many people tell me that their project disaster snuck up on them without warning. It’s easy to understand how. Once the project is underway, the day to day frenzy of managing the project, putting out brush fires and keeping the natives from getting restless can consume your day. In retrospect, after a project is thrown off the rails, people often say they should have seen it coming. Well, you can. Think about the metrics you’d need to track in advance and it doesn’t require a 50 element dashboard to make a difference. A handful of project progress measurements can give you plenty of advance warning that things aren’t going as expected. If you know you have a high risk element of the project, then creating a “Tripwire” milestone in advance of that section so you will take pause and check on that upcoming high-risk area is easy to do and can save you mountains of grief. Major US defense contracts are using this “tripwire” term now in Earned Value processes as a way of talking about early warning for upcoming project problems. A “tripwire” (think of a string of wire with tin cans on it that will make a horrid sound if someone trips over it in the dark) in project terms is often a threshold or tolerance of a project measurement. For example, if task #20 is more than 10% late, we’ll do a project review.” A tripwire should be attached to some follow up action for it to be meaningful.

Did You Take Out Insurance?

The very first person I ever met in the project management business, now almost 30 years ago, was in the construction industry. He was a very experienced project manager and he never started a plan without some contingency hidden in his back pocket. Building Commissioning was his favorite spot to hide it as I remember. “The schedule says it will take us three weeks to finish painting the interior,” he’d said to me with a wink. “But, we know that if we’re in trouble, I can throw a hundred fellas in there and finish it in three days.” It’s a lesson I’ve remembered well.

Making a management contingency is a healthy practice and it’s done rarely by project managers. When you create the management reserve (which might be measured in dollars, in man-days or in duration) you often can’t hide it. In this modern day of transparency, hiding the management reserve may be easier said than done. If you can keep the contingency to yourself that’s great, but if not, go the other way. Be very public about using it. Have a sign-off sheet that the client or management must sign indicating that they know they’re now using the contingency. This may slow down spending the reserve casually or having multiple people thinking that they can each use all of the reserve for themselves.

Emergency Preparedness

People are told to keep three days of water, medication, first aid and other emergency supplies ready at hand just in case an emergency comes your way. Do you do the same for your project? If you know there are potential project challenges in higher risk areas of the project, then it makes sense to make a contingency plan for those areas. I’ve seen some remarkable project plans that include conditional branches of the plan just in case. Sometimes these contingency plans include pre-negotiated contracts with potential resources. Sometimes they include potential sub-contracting arrangements to split off a small piece of the project for another supplier to deliver. Sometimes the contingency plan is as simple as calculating the overtime that would need to be spent if something goes wrong in a particular area.

Emergency preparedness is great but it also comes with a law of diminishing returns. Let’s take a project with 20 major elements. If we go by the 80/20 rule, we can reasonable expect four of those elements to represent 80% of the risk. I know that’s a generalization but it’s amazing how often it’s true. If we do some contingency planning for those four elements, we’ve got fall-back plans for 80% of the major problems we’ll face. We can, of course, make contingency plans for all 20 elements but we’ll put more effort into those plans than they’re likely worth. So, picking and choosing what parts of the project to do emergency preparedness for makes a big difference to your overall efficiency.

Can you plan for every emergency? Of course not. But if you don’t prepare for disaster, then when it strikes the effects on your project, your organization and even you can be awful. Pretending that disasters never happen is just ostrich management. You can’t stick your head in the sand and hope that the problems will go away. Being prepared for a disaster will make you a better project manager whether disaster occurs or not.

Don’t forget to post your comments below!

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected] .

Are you a Project Management Baseliner?

Written by Chris Vandersluis on June 24, 2009. Posted in Articles. 5 Comments on Are you a Project Management Baseliner?

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.

What is 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 severe 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 have to report 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 expenditures. 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 just getting started with baselines often think of them as an inviolate set of records; 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 follow 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, whatever you decide, be sure that the original baseline is retained 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 or 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 explaining 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 crept 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 not be managed at all. No one admit 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, missed deadlines and exceeded 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, 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. But, much more important, is what you’ll do when a variance occurs The best practice is to define a series of thresholds and some kind of process that is triggered when a threshold is exceeded. It can be as simple as a project review by a senior manager but some kind of process should be initiated when a threshold 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 way 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?

EPM is Pronounced PMO!

Written by Chris Vandersluis on May 27, 2009. Posted in Articles. 3 Comments on EPM is Pronounced PMO!

“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 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 one must be able to integrate at some level with the data from project two 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 and 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 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. Moreover, you’re going to have to think about the future. Even when 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 for ensuring 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.