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/100th 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.
