It’s the Holy Grail of project management. The idea that all project management information, reporting and analysis will be part of an all-encompassing system where virtually every activity, every hour of time and every doll spent can be instantly identified. Management has desired this since they built the Pyramids and in this age of computer systems, enterprise project management (epm) has become a hot topic.
It’s not just senior management that is interested in the subject although at first glance, you’d think they have the most to gain. The Project Management Office (PMO), or in its absence whatever level is available of professional project schedulers and project managers, are highly interested in getting access to all levels of data regarding project management. The antithesis of enterprise project management would be an ad-hoc process where everyone does there own thing. This is by far the most common scenario we find in organizations today. A PMO can’t function without project data and if everyone is doing their own thing then data isn’t easy to come by. For the PMO, getting to see the lowest level of project data is very attractive.
Individual team leaders are interested in seeing the inter-project impact of different project groups and the ability to resolve resource conflicts between teams is one of the most significant impacts on project performance.
Even team members are interested in the concept. Team members in organizations which manage ‘by emergency’ or continuously in a reactive mode, see tremendous potential benefits in epm in the hope that an integrated process might bring order to chaos.
So what is this phenomenon we refer to as epm? Like most three letter acronyms, epm is bandied about like a complex mysterious topic but its basis will be familiar to anyone in management. Enterprise project management is essentially the integration into a single system of project and resource data, processes and analysis for projects in the organization.
For any organization that manages more than one project at a time or which has projects so large they must be broken down into component sub-projects, the management of two significant elements is critical:
First is the interrelation between projects. If any project is dependent on the completion or delivery of elements from another, the impact of changes in one project can have dramatic effects on the second. For example, one project might be to install a new database on which new software deployments will depend. If the database project is delayed for any reason, all dependent projects will be delayed. Having a process which allows the downstream projects to see potential impact on their projects is a fundamental goal of epm.
Second is the management of restricted resources. Rear Admiral Ken Mattingly of NASA was once quoted as saying, “The definition of project management is the production of a stated result with insufficient resources.” Anyone who has ever managed a multi-project environment knows what he is talking about. There is virtually no project management environment in the world where resources are standing around, waiting for work to arrive. More likely is that work loads far exceed the availability of key resources to accomplish them. The prioritization of that work and the resolution of conflicts over those resources is a prevalent management concern in organizations around the world.
The Project Management Maturity Model
There is much talk lately about a Project Management Maturity model (PMM) which would match the work done in the IT industry of a Capability Maturity Model. While it’s not the subject of this section, it’s worth taking a moment to see how these two TLAs (Three Letter Acronyms) interrelate. There are several versions of a Project Management Maturity model which are popular but their root is the same. The notion is that the lowest level of maturity would be one where project management is done on an ad-hoc or casual basis with each project manager managing things their own way. A middle level of maturity would see these processes integrated across the organization and a top level would see a process by which the integrated process itself is self-sustaining through a formal change management and improvement structure.
It’s an interesting concept but it takes as its central premise that organizations are more mature if their project management is integrated and this is not necessarily the case. There is an argument to be made that for some organizations, the most effect enterprise standard for project management is to have no standard; to eschew the concepts of enterprise project management altogether and to let individual project managers use whatever systems they wish. It is a trade-off to be sure but worth taking a moment to think about.
The potential benefits to management of epm seem obvious but they come at a cost. The implications of a centralized structure will serve to implicate several levels of management in project decisions. This may give management better visibility but it will hamper the aggressive “high-flyer” project managers who have fought, connived and scrapped for the internal competitive advantage. Each organization should look at what level on the Project Management maturity model they should be striving for and there is a case to be made that the right level for your particular organization is any one of the levels displayed. Project Management Maturity models are discussed in detail on the web in numerous sources.
Elements of epm
The PMM model notwithstanding and assuming that you’ve decided that epm is still for you, let’s look at the basic elements of an enterprise project management environment. We’ve broken this down into five basic elements:
- Storage of all project data into a single location
- The ability to group consolidated data by different criteria
- Resolving conflicts such as insufficient resources
- Portfolio management
- The ability for project team members to inter-relate
Let’s tackle each of these separately.
1. Storage of all project data in a single location
This is a key and critical element of epm. It is the first thing that must be done in any epm deployment and, as the first element is often highly contentious. Now, before we go too much further, lest we confuse this section as having to do only with software, it is certainly possible to create an epm environment that is completely computerless. In such an environment, the basic requirement of getting all data together is still fundamental. What is most common is that different project data will be stored in different places.
In today’s modern organization many managers equate control of data to power and there are few managers who will willingly sacrifice what they consider power. Each aspect of project data will likely be jealously guarded by its incumbent owner. The budgets may, for example, be part of Finance. Individual teams of resources may be managed by department managers. Each project manager will have their own schedule data which they are used to controlling. For an enterprise system to be possible in any way, all project data must be stored in the same place and managed in the same way.
To bring data together, there is some work to be done. Let’s start off with naming conventions. For example, if we talk about project resources. Let’s assume that one group refers to the CEO as ‘ME’; short for Mike Edwards. Another group uses the letters ‘ME’ to refer to the discipline of Mechanical Engineers. Yet another uses ‘ME’ to mean Maintenance Engineers (i.e. Janitors). If we don’t first come to some understanding of what coding we will use for resources, when the data is brought together, we will find Janitors, Mechanical Engineers and the CEO will all be grouped together. This might result in your system trying to assign the CEO to push a broom and the cleaners trying to design an aircraft engine. Not such a great scenario.
To bring this data together, standards will have to be agreed upon to avoid this type of conflict. The same thing has to be done for project names, task names, department names and so on.
Now, we’ve invoked a scary word, ‘standards’. Yes, this implies that someone will be the keeper and arbiter of those standards and that almost certainly means that if you are committed to enterprise project management that there will have to be some kind of central office to be responsible for elements of your epm such as naming conventions. Without some kind of PMO, there is little hope that naming conventions will ever be agreed upon and if they are they they’ll ever be enforced.
Along with naming conventions, you’ll also have to agree on the repository for the data. If you’re implementing an epm package, then this part of the conversation is quite easy. The new system will have a set method of storing data, usually in a commercial database like Microsoft’s SQL Server. Then all you’ll have to organize is choosing the single location for that data to reside. Different groups may lobby for why their need for project management is so unique that it’s absolutely impossible for them to comply with a single repository of ‘their’ data somewhere else. These various interest groups will have to be dealt with one at a time. Your first mantra for deploying project management has to be ‘all project data, one location’ until there is broad compliance.
2. Grouping data by different criteria
The ability to group data by multiple criteria is an issue for reporting and analysis so it is often spoken of last. However, the definition of the data structure makes all those reports and analysis possible so it really needs to be dealt with first. If there is no coding of data at all, bundling all the project data together essentially will just give you one enormously long list of tasks with no method of sub-division. That’s not too useful. Once you are past the mantra of ‘all data, one location’, Project Coding is your next challenge.
Coding comes in a variety of flavors but the easiest way to think about it is grouping by project, by task and by resource. Coding further should be thought of in two large categories: codes which apply to the entire project data structure to which everyone must comply and codes which can be personalized project by project.
Some examples of coding might be:
- A project-level code which identifies the client of this project. This would allow projects to be grouped and sorted by client. This is key for client billing purposes.
- A resource-level code which identifies the department a particular resource belongs to. This would allow resources to be grouped by department as well as by project.
- A task-level code which identifies the project phase. This might enable us to create a report of tasks in different categories such as design or documentation or deployment.
Coding can be a simple list of values such as a list of possible locations for a project or can be a hierarchical tree of values such as would be used in a Work Breakdown Structure (WBS) or an Organigram of resources often referred to as a Resource Breakdown Structure (RBS).
If you are wondering how to decide what coding is appropriate to your organization, here’s a simple method of analyzing 90% of all coding requirements:
First, put key personnel into a room with a large white board. At the far right of the board, start listing important decisions that will be made using the resulting analysis or reports from the epm system. An example decision might be selecting priorities for each project. From each decision, work your way left from right. To the left of the decision, show the final report or reports that would be required in order to make that decision. An example might be a resource conflict report and a project priority report. Draw an arrow from the report(s) to the decision. Left of the report, show a box with the calculations or analysis that would have to be done by the system in order to create that report. An example of an analysis might be a resource leveling calculation of all projects. An arrow goes from the analysis or analyses to the report(s) that require it. To the left of the analysis you can now list the elements of data that the analysis requires. This list defines your key enterprise coding. There you are; business analysis 101 in a single paragraph!
Using this simple technique and involving a good representation (better yet everyone) who makes decisions based on the epm system, you will quickly determine which requirements are critical to the data being able to be grouped together in the manners you’ll required.
3. Resolving conflicts such as resources
We’re getting into some of the key results now of an epm system. For many managers most of their project-oriented time is spent trying to figure out how to resolve the conflicts inherent with insufficient resources. Not managing at all is not productive. That just makes every project a zero-priority and staff will end up working on whatever task is presented them next or worse, on whatever interests them in that moment.
Resolving resource conflicts implies several things. First of all, you’ve got to be able to deal with both resource availability and resource requirements. Next you’ve got be able to compare them. It is the comparison of availability and requirements which display any potential conflict. This may all seem obvious but remember, we’re referring to all the resource availability and all the requirements. This means that all project load must be defined in similar ways and all availability also. Some of the issues you’ll need to deal with here include deciding on the resolution of the data. In some organizations, one group will wish to manage resources at a category level (e.g. engineers) and another will wish to work at the individual level. There is no hard and fast rule which says which one is better but you’ll need to decide so that information is consistent across the system.
Next, you’ve got to make sure that project managers define resource requirements in a consistent manner. Some project managers may, for example, attempt to ‘pad’ their requirements with additional work in order to lock their project team together for an extended period. Other project managers may not and the result may be an unfair allocation of key resources.
There is a decision to be made over how productive it is to remove a person from one project and put them on another project for a short period of time. Their work load might show them available between tasks on one project and therefore attractive to put on other work but simple analysis usually doesn’t allow for the impact of changing thought processes. To make this point, think about an analysis which would indicate that you would be most productive to the organization if you worked on a task in 16 separate projects today, each lasting 30 minutes. For most project environments, we’d know this would be impossible. Just the time it takes to change gears from one project team to another and to get the momentum required to do anything productive with that team can often take a lot longer than 30 minutes. There are exceptions of course, but you’ll have to decide what kind of resources and what kind of work can pull people from one project to another.
Finally, the notion of prioritizing projects must occur. This can often be a highly contentious issue at the most senior levels of management. Any manager who elects that his or her project carry anything but the highest priority knows that can mean loss of resource allocation. We’ll talk about this more in a moment when discussing portfolio management. The idea of prioritizing projects should be part of an empirical analysis. The rules on what makes a project a high priority vs. a low priority are quite easy to get agreement on prior to deployment of your epm system and just as hard to get afterwards.
Regardless of the system you create for resolving resource priorities, you’ll need to set up some kind of referee to arbiter disagreements. This should be someone or a committee that doesn’t have a vested interest in the result.
4. Portfolio management
Portfolio management is another hot topic these days. It refers to the concept of working at the project level from the top levels of management. For some, portfolio management is all about being able to group projects together for analysis and reporting. For others, it is mostly about the approval of projects from the earliest concept to final completion such as ‘stage-gating’. Often the notion is combined with financial analysis or other management interests.
Whichever aspect interests you, the basic idea is that you are working at the project level. Think of this as a one-line-per-project report to get the idea.
Key aspects in portfolio management include the ability to code projects so they can grouped together for reporting or analysis. This is something you may have dealt with in your coding phase. The ability to organize the projects by priority from whatever perspectives are important to you is also key. Some examples include: ranking projects by risk, by return on investment, by alignment to corporate strategy, by cost, by revenue, by manager or by client.
One of the most interesting aspects of this kind of management is the ability to do forward-looking resource capacity planning. Given that all projects must now be stored in a central location, you may have for the first time, the ability to see all resource load simulateously. This enables a ‘what-if?’ analysis where the impact of a temporary addition of a proposed project can be assessed instantly. The old system where Marketing invents a delivery date based on a hoped-for schedule can be eliminated in favor of a promise based on actual capacity.
All that’s required to deliver this is to create a high-level project plan for the proposed project and then slot it into the existing system with a priority assigned. The impact on all other work when using an epm system can usually be determined in seconds. Coding must be used to allow proposed work to be distinguished from existing work so that the two aren’t mixed up.
5. The ability for project team members to inter-relate
It is most commonly referred to as collaboration. This single word has spawned a entire category of project management tools; ‘collaborative’ project management. It’s an interesting notion because collaboration is something that can only be enabled by technology, not created by it.
At its based, project management is all about collaboration. A project manager never works in a vacuum. The fundamental purpose of a project manager requires them to communicate with team members, sponsors, clients and so on. Enabling collaboration would seem to be a natural aspect of project management to enable.
Collaboration can play a key role in an epm deployment. Fundamentally, any function of the epm system can be considered a collaboration function. These usually include things like instant chatting with team members, the ability to notify team members of events in the epm system through their regular email, instant messaging or mobile device. It may also include the ability to create elements such as mini-web sites, on-line surveys, or on-line update forms.
This kind of functionality isn’t trivial. In the past 10 years, the entire project management industry has focused more on having project team members communicate and work together than it has on the algorithmic nature of project scheduling. As interesting as it might be to create the ultimate theoretical schedule, actually managing a project has everything to do with communicating and only a little to do with calculations.
One of the pitfalls in looking at epm systems which we’ll be doing next, arises in this collaborative area. There is a tendency for some managers to believe that if they purchase and then deploy an epm system with collaborative functionality, project team members will automatically collaborate. This is not always the case. If this is one of your goals in deploying epm, it’s worthwhile to ask why personnel don’t collaborate already.
Here are a couple of questions that you can ask to use as a litmus test to see if you’ve got more work to do on the cultural side of deployment than the technical side in order to enable a collaborative environment
- If project managers share their true data with the organization, will managers punish them with their own data the next day?
- Does it concern you that if you share your data with other project managers, they may use it to take unfair advantage?
- If staff members enter an entire week of work on a single integrated timesheet, will they be concerned that the data will be used to unfairly evaluate them?
If project team members aren’t collaborating now, then the reasons are almost always culturally oriented rather than technical. You’ll need to do some work to evangelize the benefits of collaborating and even making changes in procedure to ensure you remove roadblocks to participation by team members.
epm Systems
It’s a popular industry at the moment. Given the interest in bring project data all together, computer systems are ideally suited to showcase this kind of process and numerous vendors are keen to show what they can do for you.
There’s no way in a few pages to show everything there is available on the market and even if we did, these systems are being updated all the time with new functionality being released on what seems sometimes to be a daily basis. The trend in the epm systems industry is perhaps of interest. In the late 70’s and early 80’s we saw the first multi-project systems available as commercial packages. Their orientation was very algorithmic; focused on the calculation of the schedule and the calculation of resource requirements. More recently, there has been a major trend away from the algorithmic perspective and towards a more collaborative approach. This does make some sense. While the theoretical best schedule is useful information, most project managers spend most of their time working on human issues and on dynamic decision making to resolve issues that arise on the fly.
What we’ll do over the next couple of pages is to talk about some of the functionality you should be looking for in an epm system and how to evaluate it. You don’t need to look much further for a lot more information on this subject. Just go to your favorite Internet search engine and enter ‘enterprise project management software’.
Let’s start off with some basic functionality that should be considered in any epm system:
- Single Repository
The system should provide for storing data from all projects in a single repository. For very large scale deployments, you’ll need to look at functionality for amalgamating data from several large repositories into a single repository for reporting and analysis. Depending on your organization you may have to consider multi-national access, access from slow communications connections and other communications issues.
- Portfolio Management
The system should have an ability to manage at a project level, allowing projects to be added or removed at will and be grouped by multiple types of coding. A flexible coding structure should allow you to code the projects for use in a stage-gating approval system. Also key is the ability to prioritize projects for resource management purposes.
- Multi-user access
It’s fundamental. If multiple users can’t access data at the same time to view current project data and do project updates, you haven’t got an enterprise system. The system has to be user-friendly enough that non-professional users can access it with little training. End users can’t have their life become about servicing the epm system. The system should be there to enable them to do their core work more effectively.
- Enterprise coding
What you’re looking for here is first of all high degree of flexibility. No two organizations are the same and therefore no one can predict how you will need to group and analyze your project data. Ensure that the system you are looking at will be able to adapt to whatever coding you envision now and will have the capacity to extend to the grouping and coding you haven’t even imagined yet. Also, critical in this area is the ability to impose some coding as mandatory. Can the system ensure compliance with some critical code elements you have created? This is important when you are linking the epm system to other corporate systems. For example, in a link with finance systems, you must ensure that work is only coded to accounts which exist and that 100% of work be coded. Can the system impose this on all tasks?
- Collaboration
In this area, look for the simplest elements of collaboration. Does the system enable project management personnel to inter-relate? Look for automatic notifications which can be integrated into your standard email or instant messaging systems. The ability to create communications areas such as project websites which are dynamically integrated with the project data can be of great benefit.
- Workflow
In larger organizations, the ability to define a sequence of events which must occur in a particular order can be of great interest. Work flow need not be a complicated affair. Can you list a series of steps and then identify when a step has been completed? This type of functionality is important when looking at phased project approvals or when considering any kind of change management such as a change in project scope.
When looking at project software, the overwhelming number of products which purport to serve epm requirements can be daunting. Start your analysis by looking around organizations you know already. Most project management associations will sponsor events where multiple software vendors can show their wares. Ask to speak to or even visit existing deployments where you can ask not only what has gone well but what the most challenging aspects of the deployment were.
A simple search of the Internet will reveal numerous vendors but don’t be fooled by claims or even independent analysis of who is ‘best’. There’s really no such thing. Given that each organization will have a different environment, be at a different maturity level and have different requirements, it is perhaps more appropriate to ask what the most appropriate tool for your particular situation would be.
Don’t be too enthralled or concerned over functionality you haven’t listed in your list of requirements. Virtually every system will include functionality you can’t take advantage of right away. Focus yourself on your key challenges.
One of the best things you can do when evaluating epm software is to organize yourself as a ‘solution buyer’. There is much talk among software sales organizations to be solutions sellers but solution buyers are more rare. If these systems are the solution, then you should put some time into thinking about what problem they are to solve. Some organizations get caught up too quickly making a list of functions to be responded to. This list usually comes from a pre-supposed list of requirements amassed from existing systems. It’s the worst way to look for a new system. Start instead with the business challenges you wish to accomplish then ask the vendors to respond with how they will enable you to overcome those particular challenges. The response you’ll get will not only show you instantly which vendor understands your problem vs. those who do not but will also free-up the vendor to respond in a much more imaginative way and to showcase their particular product more completely.
There are literally hundreds of vendors to choose from but we’ve taken a few examples below of some that you may wish to consider:
Other vendors who may be of interest might include your ERP/Finance system vendor. If you’ve deployed an ERP system such as SAP or Oracle, you are likely to find epm components either included or available as modules. The orientation of these systems will virtually always be more financial so there is a note of caution to take here. The standard sales mode of an ERP vendor is to focus on the integrated nature of the data and on the dangers of allowing disparate data systems to be supported. However, each management perspective will color how the system should be portrayed. If you have elected to deploy an ERP solution as your epm product, then make sure it will serve the needs at each level of your organization, not just for Finance.
Deploying your epm system
Deployment is where all of this conversation becomes real. There are many challenges in an epm deployment but you can avoid most of them by focusing on a few key factors.
By far the most critical success factor is an appreciation by management of the nature of an epm deployment. Too often senior management will devolve an epm deployment to be a technical project and it is mostly not. Thinking of deploying epm as a change management project is the number one factor for success.
As with all change management projects, the next key element is ensuring you have sufficient management support for the duration of the project. This has to come from a senior enough level to ensure compliance. There may be great interest in epm from one level or another of the organization but if it is not shared by an executive who can speak for everyone who would be affected then the deployment isn’t going very far. Whichever executive is sponsoring the project has to commit for the duration. That’s longer than the installation of the epm software. A typical deployment of epm can take anywhere from several months to a couple of years from the initial concept to final deployment.
If you’ve overcome these challenges, the most significant decision you have left to make is whether to deploy in a ‘big bang’ where everyone would stop managing in an ad-hoc manner on one day and start managing in an integrated fashion the next or in a ‘phased-approach’ where the concepts and technology would be rolled out to the organization over a period of time. Start your deployment with a small group who are committed to the success of the deployment. Plan to have these people become part of a core group of users who will assist the deployment effort. They will be able to work on evangelizing the deployment, on training and on fine-tuning your project management processes.
If you are committed to deploying epm, follow this simple advice: Treat your epm deployment as a project with all the controls and structure you would use with any change management project and your chances of success increase dramatically.
