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

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

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

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

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

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

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

Work on some of these questions:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In a remarkable number of companies I visit, fledgling internal project organizations revert towards hierarchical structures. The organization becomes managed through the department or organizational structure and project managers become attached to that structure rather than an independent project office. The PMO devolves to a reporting function and in this modern era of cost cutting becomes a prime target for evaporating altogether.

How can this happen? After all, those of us in the project management industry tend to think of project management as most critical in difficult times and there is plenty of evidence to show how projectized organizations generate tremendous levels of efficiency.

To figure this out, it’s important to think of how organizations come to be in the first place.

Organizations usually get started from an entrepreneurial spirit. Company founders use family or trusted advisors to take over key elements of the company because it’s too big to do alone. This historic perspective continues into modern day accounting and business management. Organizations are traditionally organized by function, not by result. Look at any standard accounting chart of accounts and you’ll see department oriented thinking. Look at standard budgeting and it is department organized.

So department heads have traditionally had ultimate power, thinking of themselves as the heads of their own companies within companies. That’s great right up to the point where the products the company needs to create must cross these departments in order to be completed. And it is in answer to that challenge that today’s matrix organization came about.

The Matrix organization theory is relatively new but has been almost universally accepted in organizations that do projects. The idea is that projects move across departments. The power in the organization is now shared in some manner. Department heads are still responsible for their people but the project office is responsible for producing the result. Many modern day managers have grown up in world where they’ve only experienced Matrix structures in the organizations they’ve worked in. But, is matrix management automatically the most effective path? Opinions vary.

In a perfect world, the two axes of the matrix are intended to balance each other out. We’d expect that an organization that is completely oriented to the organizational axis of the matrix would have very happy employees who were well taken care of, highly trained and well compensated but would not get a lot of project throughput. Conversely, we’d expect that an organizations that is completely oriented to the project axis of the matrix would have lots of projects being completed but would be burning out staff on a regular basis, having lots of turnover and ultimately would lose its key resources. The idea of a matrix organization is that it is conflict by design. In a matrix organization we expect the two axis to push against each other with the intent being that we will find a perfect balance.

There are two big problems with this assumption however. First, not all people are created equal. Every organizations has some managers who are more articulate, more experience more forceful, more networked, better at negotiating and better at internal politics than others. Those people who are less experienced, less connected and ultimately less powerful will suffer by comparison. The second challenge is much more significant. The traditional position of the PMO is often one with lots of responsibility but little authority. Authority rests almost always with the organizational aspect of the matrix. So, when an organization is put under pressure (as happens in a tough economy) those people in authority are pressed to protect themselves. The result is often the exact opposite of what would be good for the organization.

In the economic pressures of the last couple of years, we’ve seen a number of organizations where the role of the PMO has been degraded. It’s exactly the opposite of what you’d expect in a challenging economy. We’d expect that this would be the time where the most throughput possible would be the incentive and, to be sure, in some companies that’s the case. But, in some organizations, the pressure on the organizational department managers is to grab back as much authority as possible. These groups create their own project management groups that are specific to their departments thus paying lip service to the project management requirement but at the same time removing the most powerful benefit to the organization overall: the ability to manage work across departments.

This is most common in the largest of organizations where the size of the matrix is tough to comprehend at the best of times. The end result is a weaker and weaker PMO until in the end, the PMO is, in some cases, dissolved completely in favour of “department PMO’s” which, of course manage projects only from a hierarchical perspective; that is to say, only for their own departments.

It’s a complete return to silo management by department.

If this is something you’re experiencing and you’re responsible for the project aspect of the matrix, there are a few things you can do.

First, market, market, market. Communications from the PMO are critical. We’ve always said this to our clients but selling the PMO shouldn’t ever stop once the PMO is established. An organization with lots of responsibility and little authority needs to lobby for its position forever. It’s just part of a good PMO. So, create a blog, a collaborative workspace or a website and start pitching your benefits to the organization straight away.

Next, keep your friends close but your enemies closer. It’s an old expression but it holds true today. Make sure your portfolio selection process or your project prioritization process includes those very department heads who feel they might become disenfranchised. Making sure that people in authority don’t feel left out can eliminate a huge risk to the PMO.

Finally, become Switzerland. Being the facilitator of portfolio meetings puts you one level beyond inter-department rivalry and makes you the neutral territory on which departments can negotiate. Having a neutral territory somewhere which prides itself on its neutrality rather than an organization which is looking for authority of its own is something everyone can commit to.

Maintaining a level of balance between the organizational and project axes of your matrix organization is essential if you don’t want to risk being returned to a silo organization.

TANSTAAFL – It’s an acronym meaning “There Ain’t No Such Thing as a Free Lunch” coined by science fiction writer Robert Heinlein many years ago and, as a commentary on the work ethic, it’s something I think about often. The notion that you have to be prepared to work for the results you achieve is a good one. There’s another expression that I’m sure Heinlein would have agreed with and that’s “Don’t look a gift horse in the mouth. With the ubiquitous Internet available to all of us, there are many tools available to project managers that are absolutely free, and I thought I’d spend a moment pointing some of them out.

Gantthead – www.gantthead.com

Gantthead burst onto the project management scene over 10 years ago. Their model was to be a center of excellence for project management information, and they’ve done a fine job. There are thousands of project managers who visit the site on a regular basis. One of the draws on the site is the remarkable number of articles, processes, downloads and other free information. Just sign up for a free login and you’ve got instant access to tons of information.

Microsoft Office Online Templates – office.microsoft.com/en-us/templates

If you’ve got any recent Microsoft Office Product, then clicking Help will bring you information from Office Online. This is an area of Microsoft’s website that carries templates for all sorts of products. Don’t choose the product first – just do a search on Project Management or just Project and you’ll find templates for MS Project, but also for Visio, Excel, PowerPoint, Access and even Word.

US Small Business Administration – www.sba.gov

The US Small Business Administration gives away a ton of information to those interested in creating a small business. A lot of this information is of use to anyone doing project management. It’s worth browsing around for 10 minutes to see if the online courses, templates for business plans, or articles are of any interest.

ITeamwork - www.iteamwork.com

This free use site allows you to use the web-based system for creating a list of tasks, assignments and notes and seeing your tasks online. It’s best for smaller projects where you can work online.

AceProject - www.aceproject.com

Here’s another interesting hosted system. It’s free for up to five users and five projects. Users can then log into the hosted site to see their assignments. You can schedule tasks, assignments, manage inter-project workload and more. If you’re a small team – it’s a tough deal to beat.

TaskJuggler – www.taskjuggler.org

More free scheduling and resource management software. This one is a Linux/Unix product available for downloading and use by a project manager who wants to see a Gantt and other key information about their project. It’s an Open Source product.

Project Workbench – www.openworkbench.org

This product is a free open-source download of the old Project Manager Workbench by ABT. ABT was bought by Niku, and Niku is now part of Computer Associates but the product still has depth and a strong set of tools for scheduling projects, grouping them into portfolios and assigning resources. Workbench was popular among the IT scheduling crowd. The publishers decided to make this product open-source and freely available for download years ago while they concentrate more on their enterprise project business.

Google Documentation – www.docs.google.com

How can you beat this? The free Google Docs service lets you upload files or create them on the fly. Since you can share docs with others in your network, you can create an easy to access site for document collaboration almost instantly.

Bluetie – www.bluetie.com

Got a project team and need an online home to collaborate? Check out Bluetie. You can become your own “Enterprise Manager” for free and add your project team right online with their own user logins. Then add tasks, contacts, calendar events and documents, and then see your to-do list along with how your team is interacting. You can upgrade to the commercial service if you need more people or capacity. If you’re keen to create your own collaboration environment, then take a look at SourceForge (below) there are numerous Windows and Linus Collaboration portal tools available for free download. Just search for “Collaboration” “Portal” on the SourceForge site.

SourceForge – www.sourceforge.net

There’s too much to list here. SourceForge is a huge repository of open-source products. Some are available for Windows, some for Linux, some for Mac and some for multiple platforms. You’ll find everything from web-based project offices to collaboration tools. Do a search on “Project Management” for literally hundreds of possible downloads.

There are many free tools and services but it’s worthwhile thinking for a moment or two before you jump on board with one or more of them. First of all, just because software is free to download doesn’t mean that the TCO (Total Cost of Ownership) will be less than if you purchased a product from your regular supplier. Here are a few things to think about:

Support
How will you get support for this product? Will you have to hire someone who is an expert in that programming language or that software platform in order to be sure that you get the service you need? In some cases, you might find an open source product but not on your most commonly used platform. We have seen products in our office, for example, that would work only in Linux and the total cost for us in using them would have had to include adding personnel, or training personnel in skills that are not part of our core competency. With an Open Source product, will you have to do your own technical support? There’s no one to complain to if a calculation is wrong. If this is for a small personally run team, then perhaps the impact of such problems are minimal – but you need to think about this carefully in a corporate context.

Licensing
If you’re downloading “Free” software the license agreement is something that you might want to take a few minutes with. For example, some license agreements put responsibility on the end-users who use the software. These obligations might include posting any changes that you do to the product and not embedding the product into something you resell without offering royalties to the original publisher. Again, for the individual this isn’t likely to be a concern but in a corporate context you need to take a moment to be sure this is what you want.

Migration
Sometimes we’ll start on a product or hosted service with the notion that it looks just right for our team. But what happens if you expect down the road to move this information to a corporate system? Will you be able to extract the data in the format you need and migrate it somewhere, or will you be caught re-creating that data when you eventually migrate?

Backups
With a free hosted service how canl you be sure your data is properly backed up? Given what you’re paying (nothing!) there’s not a lot of leverage to complain when your project plan or your bid documents go missing. Check with the service to find out how you can be sure your data is safe.

Free Hosted Plans
With all the free-hosted plans, the service agreements state that there’s no guarantee the service will continue to be free or, in fact, continue at all. So, what is your contingency plan if the service evaporates overnight? Do you keep off-site backups? Can you recover your data if need be?

In the end, Heinlein has a point: There Ain’t No Such Thing as a Free Lunch. Still, some of these free products and services have some great capabilities and functionality and are worth keeping track of. The “Free” hosted services are almost always attached to paid-for services that are also extremely interesting. Go into these products and services with your eyes open and you might just find a gift horse.

At one time the notion of a communications 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 barchart 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 communications 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 resource 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 be in communication 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 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 tools 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 setup 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. Wiki’s 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 practies, 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 documetns 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 communications plan can be rounded out with creating some templates for regular communications 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 communications 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.

I hear it all the time, at least a couple of times a week, “We’d like an Enterprise Project Management System.” Given that I spend a lot of my time speaking with project personnel in Fortune 1000 companies it’s pretty clear that this desire for a global perspective on project management is almost universally desirable. It’s easy to see why any executive would be keen for such a system. The new economy has dictated a movement away from large mega-projects with their attendant Project Management Offices where project management would be easy to manage from the top down. What today’s business world favors is a large number of smaller, more maneuverable projects, each controlled by small number of employees and often sharing resources with many other projects. It’s highly effective from a communications, motivation and flexibility point of view (that’s what is critical in today’s fast-paced economy) but it’s a killer to manage from an executive perspective.

Well, with all this desire for an enterprise system, it’s no surprise to find that virtually every project management system on the market is suited for “enterprise-wide” use. At least that’s what they say on the box. The funny thing is, this demand for centralized access to project information was not created last week. It’s been with us since the early 90′s at least. There are a number of project management products which really can lay claim to enterprise-wide functionality yet, week after week, companies ask me if there’s any hope of them actually finding one they can implement successfully. The disconnect between happy enterprises and the number of products which claim to be able to make them happy has to make you wonder.

The problem certainly isn’t that all software publishers are liars (although I’m not promising that we’re not) or that all project management products really don’t have enterprise-oriented functionality or that there are no differences between these products. I review project management software all the time, and there really are some differentiators which would make some more suited for enterprise use than others.

Most project management systems can now be implemented with a client/server database as their repository. I think this ability is critical to having any chance of bringing enterprise project data together. This was once the purview of only the largest, most complex systems but it’s now almost universally available. Systems which had this enterprise architecture used to be difficult to use and thus difficult to deploy across the enterprise but Microsoft’s standards for ease of use have changed that for everyone. Desktop planning systems like Microsoft project are the most widely distributed project management tools in the marketplace. It is now almost a given that every company will have Microsoft Project somewhere in their office.

So what’s the problem? We’ve got database connectivity, ease of use; that’s it then isn’t it? Well no, unfortunately it’s not. The problem with bringing these users together is more fundamental than a database selection or ease of use. A visit I paid this week to one of the world’s largest insurance companies exemplifies the point. This company has over 2,000 project managers spread across the enterprise. Some of them are working within business units which have chosen a particular project management tool, some are working in a more independent fashion. There are thousands of copies of MS Project in the office, it is the most widely held project management tool and yet virtually every day, someone in the company is lobbying for why the company should accept the product they’re using as a corporate standard. With all the users to be wooed, project management vendors swarm the reception desk on a regular basis with their latest wares, upgrades and offers. The company has now determined that despite having some very skilled project managers, that the company executive is handicapped by not being able to report on all project work at once or to be able to influence the project process by injecting management perspective data such as project priorities. Management has now allocated a significant budget to resolving the problem and so possible alternatives are being considered.

Proposed solutions come in a variety of formats. There are still the venerable project management firms now with new updated products. These companies have the most years of experience with implementing systems across the enterprise from the early project management software days when an enterprise often referred to a mega project. There are tools which claim they will automatically deliver an enterprise wide system because they are so easy to use that everyone will adopt them. The problem is that while ease of use may guarantee the widest deployment, being compliant does not make you integrated. Finally, there are add-on or layered products trying to bridge functionality. Their pitch goes like this; “Keep your Microsoft Projects. We’ll operate as a layer underneath them automatically imposing the centralized standards that are essential to delivering an enterprise system.” It’s this latest group that has the most insidious approach and it’s that group of products that I was asked about this week at the insurance company.

I had for my friends some bad news though. There is no easy path between an independent desktop planning system and centralized control I told them not matter how important management decides that is. The problem isn’t technical. Technical solutions for bridging these kinds of products have been around for a long time. The problem is cultural.

When you ask management what it is they mean by an enterprise system, the answers are almost always the same. They would like to bring project data together into one source in order to do reporting and analysis across the enterprise. When you ask individual project managers why they insist on sticking with a desktop planning system, their answers are also universal. They want ease-of-use and an ability to manipulate the data quickly on their desks to reflect what they want to track today.

These goals are almost certain to be in conflict. In order to be able to gather data together and analyze and report on it, we need to impose some standards. For example, I can’t use the code ME to refer to Mike Edwards, Mechanical Engineer and Maintenance Engineer (i.e. Janitor) in three different projects if that data will one day be brought together. If I do, Mike, the engineers and the janitors will all make up the same histogram bar in a resource analysis – it won’t make sense. If I want to bring this data together, I need to impose controls across the company.

The bad news is that the degree to which I need to impose those controls is the degree to which end users will wish to abandon use of the product. It goes directly against the maneuverability that attracted them to their favorite tools in the first place.

So, is there hope? Of course. I’m often caught quoting Napoleon Bonaparte with my favorite project management quote, “A battle plan lasts until contact with the enemy.” I’m sure however, that Bonaparte didn’t mean that we shouldn’t plan.

My advice for the insurance company was to reset its goals. Think process, not product is my suggestion. If you need to impose standards, impose the very fewest that you can think of. Don’t stress over getting every minute change in a resource plan to reflect into a top-level project resource analysis. Work instead on the broad strokes; project management training, project reporting standards and good planning practices and let the managers manage.

Awhile back I had the great pleasure of sitting in on a round-table discussion aother project managers and doing peer-to-peer learning is by far my favourite. The topics in this case were on placards at each table and you could just select the subject that was of interest and sit in for a half-hour discussion. “A successful Project Management Office (PMO)” caught my attention and I sat in on both sessions to listen in.

I was not at all surprised to find several varied opinions about how to make a PMO successful but what was most interesting was the wide range of ideas over what constitutes a PMO and what its purpose should be. If you’ve read my column before you know that my focus in the industry is on project management systems but imagine the challenge for someone in my area if it is that difficult even to define a PMO. Let’s take a look at a couple of different perspectives of what a PMO could be:

The Owner
It’s the rarest of all PMOs. In this scenario, the Project Management Office has ultimate authority over every project manager. The project managers report directly to the PMO. We see this most often in a mega project environment where the entire organization has been created in fact, to accomplish a particular project. It can also happen in Defense and Aerospace projects where the government has imposed project management standards which define how the organization must manage. In this environment we’re more likely to find a small centralized project management office staffed by highly skilled full time project scheduler and project cost analyst personnel.

The tools that are chosen for this situation are heavy on the analytics and light on user-friendliness. Compliance and collaboration are not the first concerns here. What’s more important is that we can do strong forecasting, strong project accounting, that we’re able to have sufficient flexibility to integrate directly to the organization’s ERP and corporate reporting systems. We focus more here on government or contract compliance so we’re more likely to find things like requirements for Monte Carlo risk analysis and Earned-Value standards for cost analysis.

The Coach
(No, not the couch – that’s where PMO staff go after a long day!). Perhaps the most common PMO role today is that of mentor or coach. They’re not there to impose their authority on a project or on the project manager but rather to be there to guide the Project Manager, to offer assistance if needed, to provide tools and resources in order to help the project get out of trouble.

In this case, the PMO is more likely to be a small, highly skilled group and extremely unlikely to be hosting a strong centralized enterprise project management or enterprise portfolio management system. They’re more likely to offer tools that each individual project manager can use and to facilitate training exercises and the delivery of easy-to-implement templates. There’s not much room here to police the projects under the coach so the role is supportive rather than prescriptive.

If it’s all about supporting others, the ability to disseminate information is more important than our ability to collect it. So, we look for tools that are strong on document management, strong on communications and light on centralized analysis.

The Scout
Many PMO’s are set up like the Defense Early Warning (DEW) System of cold-war fame. The purpose of the office is to identify potential problems within projects and to report back on this to management. Scout PMOs don’t have much authority but often they are much more than reporters. After all, if they can identify the problems early on, why not try to tackle them up front. It’s not unusual to find a desire for an enterprise project management system here but deploying one can be a challenge. The Scout PMO is often empowered from the highest levels of management and that’s a good thing if you’re trying to deploy an EPM system. However, they’re often viewed with suspicion by the project managers themselves and that’s an awful thing if you’re trying to get the cooperation you need to get an EPM system used by everyone.

Systems for a Scout PMO will be strong on data collection, strong on reporting and a little lighter on heavy analysis. Assembling information from numerous disparate sources into a single view for management is almost impossible so the Scout PMO will lobby heavily for data collection and tool standards as well as some semblance of standards for projects such as coding for stage gating phases and project durations.

The Facilitator
While it’s not yet the most numerous, certainly one of the most desired types of PMOs anywhere is that of the Facilitator. This kind of PMO doesn’t have authority over the rest of the project managers yet it doesn’t have a passive role either. The PMO’s role is to facilitate the execution of the projects under its purview. This means that the role includes that of the Coach and the Scout. It’s often said that a facilitator has the toughest role in a negotiation. They are held responsible for the result but carry no authority to generate it and that, indeed, is how it works in this environment also.

The Facilitator PMO will have the backing of senior management but will be a dotted line on the organigram. Without authority, they will resort to cajoling, threatening, inspiring, evangelizing and pleading in order to produce the result and it’s often very successful.

The PMO will be characterized by a small cadre of highly trained and highly charismatic personnel. We’re most likely to find a successful Enterprise Project Management system implemented with this kind of PMO. Communication and collaboration are very significant desirables in this scenario and that is often a key to making an EPM system work. Also, centralized information is essential to the Facilitator being able to identify areas in which project managers, team leads and management must collaborate so getting all project data into one place is going to be an essential part of making the Facilitator PMO successful.

There are other kinds of Project Management Offices so if I’ve not mentioned yours or if yours is a hybrid of the couple I’ve described, don’t fret. The point is that before you head off to choose project management software ideal to your PMO or before you start to implement the project management software you’ve got, it’s worthwhile to think about what role you’re trying to fulfill. None of the definitions I’ve listed are the “best”. They’re all specific to what an organization is trying to accomplish and the particular business challenges they are facing at that time. In fact, it’s not unusual to see the role of a PMO change over time as the organization it serves changes.

Most high end enterprise project management packages these days have so much flexibility that they can be deployed in many different ways. You can focus on so many different aspects of these systems that they can easily support many different PMO scenarios. So, think about your PMO scenario before leaping directly to installation and training of the system you’ve chosen.