Enterprise project management

So, the first order of business is probably determining the basic goals and benefits. After all, you’re going to need to sell this to several layers of the organization so knowing what you could get out of this exercise is essential. When you’re making your list of benefits, you’ll need to think about them from different perspectives. In order for an enterprise project initiative to succeed, it will need to be supported by management, by professional project managers, by IT support personnel, by resource managers and by front-line team members and you’ve got to be able to answer for each of these groups the fundamental question: “What’s in it for me?”

Once you’ve got the basics outlined, it’s time to turn your management. While there is a theory that enterprise project management can be escalated in a groundswell from the ground up, the truth is, it’s an unlikely scenario. If management does not perceive some kind of problem that they believe will be soled by project management, then you’re not likely to receive any of the resources or the authority you’re going to need to make this work. So, start looking for a project sponsor that will stay the course. Someone hoping to make a quick success story and then move on isn’t your first choice. You need to look for support as high into the organization as you can find. The most successful enterprise implementations in my experience have all started with very senior management support.

Your next stop is going to be the establishment of a proper Project Management office but lets pause here to re-establish the plan. This is the best moment to flesh out the complete project schedule and to build the project team, identify progress milestones, recognize resources, mitigate risks, establish a budget, and firm up the schedule.

Ok, you’re ready to go now. You’ve got the company agreeing to your budget and some resources to get started. Next stop is the Project Management Office (PMO). Some people wonder why start project management with the people who are probably most skilled. The answer is simple. You’ve got to create a core competency and a recognized source for the changes that are to come. Without establishing a PMO with some level of authority, change requests will come from every level of the organization and no one will be able to arbitrate which should be implemented and which abandoned. Establishing a PMO is critical to the next stage of agreeing on a project management process. Establishing a PMO is worth of a book for itself so there’s no way to cover it all here. But make sure the PMO gets management level support, authority to make changes and a very high profile as an organization that will help other elements of the company.

Once the PMO has its core team assembled, its first order of business is to begin creating and documenting a project management methodology which contains the practices and procedures necessary to bring project data together. This is a good opportunity to establish a collaborative process rather than to dictate to the other levels of the organization. Many very viable procedures will exist already, created by people in the field who have the experience necessary to create best practices for your organization. Take advantage of the moment to include the ideas of as many people as possible and make sure you share the credit very publicly. There’s nothing like seeing the authorship of a particular procedure in the form of a thank you to make a new ally in your quest for enterprise project management.

You may well be months into the process now but there is more to go. Once you begin looking at project methodology, you’ll need to start thinking about tools. There are hundreds of project management software vendors out there and it is very likely that one or more of them have tailored a project management tool to fit the process you’re developing. Talk to the vendors, explain your process and ask how they fit into it. Many of these vendors have been around the industry for years and will be able to contribute some of their experience during your methodology phase. You’ll have to separate out the hype from the pearls of wisdom, it’s true – but it’s probably worth it.

Once the tool is selected, then you’re ready to start deploying your newfound methodology on top of it. There are a few words of caution here and I’ll use them to talk about the necessary evils of Pilot Projects. A pilot project is a limited time implementation of a subset of the entire group and/or a subset of the entire dataset to be managed. Many firms turn to the idea of a pilot project to mitigate the risk of a large-scale deployment that could go wrong. Unfortunately, many organizations underestimate the type of implementation that an enterprise project management represents and think that a short term trial of software will be able to sooth all the concerns that exist. It’s almost never the case. If you plan to make a pilot as part of your implementation project, then stick to these rules: 1) Commit the pilot group completely – don’t make it a trial. Pick a group and tell them they are now going to switch from now on to the new system. 2) Make defineable metrics. Determine before you start what it is you are testing for. If it is until “everyone is comfortable”, you may be in for a long wait. Set the goals so they can be measured and then measure them. It’s tougher to get people to agree to before you start but will make you much happier in the end.

Your final task is to ensure the process is reiterative. A project management process which starts from one level and only moves data in one direction is ultimately doomed. You’ll be doing a lot of evangelizing during this project and you want to be able to tell people at every level that there are benefits for them. This is only possible if the process has some cycle to it and delivers data and/or analysis back from each level to all the other levels. No, not everything should be open for everybody, but everyone’s contribution adds to the fabric of the project process and the benefits of the overall process should be enjoyed by all.

Finally, many people ask me how long a schedule this should be and the question is difficult to answer. It depends, of course, on the nature of the company, the size of the project, the number of people involved and the degree of existing project structure in place. It is not unusual, however for a schedule to last from 18 to 36 months.

Wait! Don’t gasp. There are going to be milestones along the way where you will already be able to show a return on investment. Creation of the PMO for example, often brings short term benefits. Likewise with the creation of a formal project management process and the implementation of tools. You should be looking to have this project start paying benefits early on. Even if this makes a longer process overall, it will be worthwhile to ensure each phase gets to some gateway or milestone where the results of the exercise of that phase can be returned to those working on it. This will go a long way towards keeping management investing in the process and ultimately to make the process stronger.

Good luck!