Microsoft has posted my latest article, Creating an EPM Deployment plan up on the Microsoft Project Server TechNet site under the Project Server 2010 area.  The article looks at those elements of a deployment of an Enterprise Project Management system that are much more than the installation and configuration of the tool itself.  When you take into account the management intervention, the change management implications and the overall impact on the enterprise, the project becomes more complex.  It’s a good starting point for those looking at moving to enterprise collaborative tools for project management and, if the organization already had much of this done, perhaps they can move quickly to the automation aspect of the project.

We spend a lot of energy in project management circles trying to determine how to do a thing. In my travels to various parts of the planet something that’s sadly lacking in many places is good judgement on whether we should do that thing.

I’ve told the story before of an engineering organization that was looking for a new timesheet system. This sounded like good news to me because our own TimeControl timesheet system is a good fit for engineering firms. Yet, I was less happy when I heard the reason why the customer felt that their existing system was no longer able to meet their requirements.

“We’re having to do a whole manual transfer of data from that old system to our Finance ERP,” explained the technology specialist. Because they need 3 rate values and our existing timesheet can send only two we’re having a miserable time with all this manual intervention trying to get a third value stored and sent. Can you that with your TimeControl?”

TimeControl was certainly capable of sending multiple rate values, I assured the specialist but I was at a loss to understand why they needed such an interface in the first place. In the end, after some discussion, the client agreed to pay for a day of system design and I scheduled some time in the offices.

Our meeting together started off just great. They had the CIO in the room and I was suitably impressed that the head of the IT department was sufficiently interested in the problem to attend himself. He and the technology specialist took turns white boarding the problem By our mid-morning coffee break we had a combination of boxes, diamonds, circles and lines in the four basic white board marker colors all over the board.

I took copious notes.

By the break though I had my first intelligent question. “What was the volume of transactions,” I asked, “that was being handled through this manual process?”

No one knew the answer.

“Can we ask the CFO?” I asked.

A quick call was made. Yes, the CFO was keen to talk to me but could only do so over lunch. I was delighted. Senior management intervention at such a rapid pace isn’t that common and indicated to me that management was committed to get this problem handled. Things were looking good.

We worked for another hour on the white board diagram. I headed to lunch with the CFO, the CIO, and the technology specialist that had called me originally with a good understanding of what they wanted and the kind of time it was going to take to create. The CIO and I agreed that changing the timesheet was fundamental to the new solution and that 6-8 weeks of developer time to automate this “archaic manual transfer process” sounded quite reasonable. I was upbeat. Sounded like some business on the way.

Yet, there was something niggling at the back of my mind. The whole premise of the problem came back to a lack of a single field in the old system and its inability to move that column of data to the Finance system. I’d already determined that this data was critical to the corporate effort “Why not just give up on that extra data,” I’d asked. “What would happen if you just didn’t transfer the data?” The CIO had told me he’d already considered just that and that management had made a good case for this data being essential to their ability to bill accurately.

Time for lunch. We went across the street for chicken. (Business lunches always seem to be feather, leather or fish!)

I sat across from the CIO with the CFO to my left. The technology specialist was across from him. We exchanged pleasantries and then ordered and while we waited for our meal, I turned to business.

“I’m here to work on this timesheet system to finance system interface,” I explained. “The CIO here and your technology specialist have been describing the challenge but perhaps you could describe your understanding of it in your own words.”

The CFO to his credit describes exactly what we’d been talking about all morning. This was a good sign. Often when you go back to the client or end user of a system, the understanding of the requested change isn’t at all what IT understands.

“Now could you describe how you handle the interface now,” I ask.

“It’s an archaic manual intervention,” he describes. Again, sounds just like what I’d heard this morning.

“And how many transactions are managed through this archaic manual intervention?” I ask.

“Oh about 5 a month,” he says.

There’s silence at the table.

“Five,” I repeat. I see the CIO’s jaw drop out of the corner of my eye.

“Yes,” says the CFO.

“And how long does it take to do these transactions manually each month?” I ask.

“Oh, it takes one of my staff about 20 minutes,” he says.

“Excellent,” I say, my heart sinking as I changed the subject.

The CIO couldn’t meet my eyes. We finished our meal and headed back to the office as we did so, he walked next to me. “I’m so sorry for wasting your time,” he apologized.

“No need to apologize,” I said. “I’m just happy we figured this out before spending 8 weeks on writing the interface.”

The time to recoup a return on investment from the effort we’d described would have been many years. At 20 minutes a month there was no point in doing the work. In fact, the company had already spent way too much time working on how to do it already.

Could we do the work? Sure. But we shouldn’t.

And sometimes that is the most effective project of all.

I was working with a large Canadian company recently, helping with their enterprise project management processes. As part of my work, I got to watch while a project control officer prepared a report for the Chief Financial Officer.

It was a work of art.

First data was grouped together from multiple projects in the desktop version of a popular project management system. That data was copied and then pasted into a massive Excel spreadsheet as core data for what would become this report.

Now, this person grouped the Excel data and sub-totalled it. Next, a series of macros that were clearly cleverer than I am, created an entirely new Excel workbook with the data now grouped and sub-totalled in a completely different way. The project staffer now reviewed several thousand lines by eye, looking for discrepancies. When they found them, they returned to the first Excel cut-and-paste file and deleted lines, added lines and changed values so that the resulting final spreadsheet would be grouped in the manner they requested. When data really didn’t seem to make sense, it was removed for ‘later analysis’. The über-macro was run several times until finally the results were to this person’s satisfaction and then a second tab in the newly created Excel sheet displayed the data with lovely coloured headings and columns.

I was visibly impressed. But not in a good way.

During a report I made much later, one of the comments I made to the senior PM management was, “This report has a 100% chance of errors each month yet even though everyone knows how it is being produced, it is being interacted with as though it is financial quality data at the same level of quality as your payroll or your financial statements. You are making critical business decisions with this report that you know is flawed.”

The company took steps to improve their reporting process and created checks and balances to make sure the decisions they made were done based on information that they had a higher level of confidence in but the whole experience made me think about a deeper lesson that we can all take home. I wondered if there wasn’t incentive in the organization for this person to become the ‘indispensable project manager’; the person who is absolutely essential because they’re the only ones who can create the organization’s critical project reports.

We all have methods and processes in our project management environments that we’ve created ourselves and that can really only be accomplished by ourselves. If in this company, the person in question had to take a leave of absence, no one else on the planet would have been able to generate the report they did. That’s a risk factor for the PMO and it makes me wonder how many more such risk factors do we all have in our organizations.

The top level of virtually every Project Management Maturity (PMM) Model is to have the process be self-sustaining and self-correcting. Different models use different terms but the idea is the same. The original Capability Maturity Model developed by Carnegie Mellon University used the term “Sustained” for their top level 5 definition. This level of maturity indicates that the project management process can sustain itself and adapt or improve as changes occur. This would include, of course, changes in personnel which is always a risk factor to a process.

If the process was sustainable, then the steps to create a report, a method to test the report for accuracy and a schedule of when and how the report would be created would all be present. Hopefully this would be part of a much more extensive project management process guide that would include not just how to create a report but also the methods by which the data was collected so that we’d know the source information had quality as well. We often make important business decisions based on project data and there is often an assumption that the data is accurate because of how nicely it’s displayed yet it’s common to find project environments where data does not have verification for accuracy and where this is a poorly documented process.

I’ve been a big fan of a phased approach to things for a very long time so it’s a bit of a problem to me to find that the top level of the PMM process is often the last one tackled. I far prefer making an element of the project management process stable and then bringing that element all the way to the sustained level. Document the process, train the staff, repeat the steps required over and over, produce value from this one step and etch a groove for this one part of the process deep enough that it becomes ingrained in the corporate culture. Then build on the same method on the next element.

There’s a plus and minus to my thinking of course. On the plus side, the project elements I work on this way typically last a very long time. On the minus side, organizations rarely get to all the elements they originally envisaged. There comes a point where sufficient value is being produced by the elements of the project process that have been successfully adopted thus far that the incentive for additional investment is reduced.

From my perspective working on organizational project management, the pluses far outweigh the minuses. The bonus from the phased approach is that the process has power rather than an individual personality. There is no hidden, secret knowledge. The whole objective of a publicly known process is that everyone knows how the process works from start to finish. It’s all documented and all on the table.

Virtually anyone can make this kind of difference in their own project organization; small or large. Start by giving knowledge away by documenting how you get things done. If you’re in charge of a PMO, you can encourage team members to share their best practices and make them available to others but you don’t need to be in charge of the PMO in order to do this. It may seem counterintuitive to share your best techniques but don’t worry. Expertise isn’t a depleteable resource. You can generate new expertise tomorrow. Giving your expertise away and working to create your successful project management element as a sustainable part of your organization will have you leave a legacy; some difference that can last long after you’re not longer in that role.

After all, aren’t project managers about having others be more effective? That’s a real indispensable project manager.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.