Five steps to starting project management
Let’s talk about how to build a project management capability where you have no existing project, program, or portfolio management. Work may exist and sometimes be called “projects,” but that word does not yet have much meaning.
1. Define your authoritative project list
Even though the word project doesn’t mean much yet, you need to create a single source of truth that lists your organization’s projects. This list should ideally be auditable, and at the beginning can track just a few things:
- Project name
- Project manager (i.e. the person responsible for ensuring this work is complete)
- Status (at the very least, “Requested,” “Active,” “Complete”)
- Next review date (i.e. the next time the project needs to be talked about more formally)
There are many, many project management tools, and I’m not asking you to invest in one. At this point, I’m asking you only to have a list–maybe even in a Google Spreadsheet.
The other half of building an authoritative list is destroying all the other sources. Do people have sticky notes, Excel files, whiteboard lists, or other places where they’re trying to track all the projects? Review those lists to make sure you haven’t missed anything, and then destroy those lists. At the same time reinforce that people should start checking the freely-available authoritative list. (Please do this in a nice way that helps people understand what you’re doing. 🙂 )
2. Begin building your project review process
There needs to be some way for that list to be changed in a controlled and communicated manner. If a project manager decides a project is complete, for example, should the list just be updated? Or do other people need to agree before the project is marked complete?
Similarly, what if a new project comes along? There needs to be a formal way to move that project from “requested” into “active.”
Building your review process can take a while, but at the beginning just identify a meeting where stakeholders will come together to talk about projects. For an IT organization, this meeting should include the CIO. The senior management need to know about the projects under discussion and they need to be able to express their opinions. Otherwise they may more passively stall a project they don’t feel should be active.
As an aside, building a review process will create frustration. As long as you stand firm on having the authoritative project list, this frustration should be productive.
First, senior management won’t want to see little stuff on the projects list (e.g. slight modifications to a report). This helps people think more about what they really want to be a “project.”
Second, people generally will be frustrated with old/incomplete project data being presented to them. This creates an incentive for the project managers to keep the data accurate, because it’s clear what data are needed for decision-making.
However, be aware of a few dangers to avoid at this stage:
- Try very hard to limit the fields you are tracking on the project list. People will most likely want to add dozens of new fields because (to be frank) it’s easier to talk about fields to add than to make prioritization decisions. Prioritization decisions are the worst.
- When resource/time management comes up (and it will come up, e.g. “do we have the people to start this work?”), plead immaturity: portfolio management needs very mature scope, project schedules, and resource allocation to start identifying whether there’s capacity for more work. To some extent this is a feint, because the real goal of addressing resource management is for functional managers to have primary ownership for whether there’s capacity for projects. Even in a very mature project organization, the functional managers will know the lion’s share of how people’s time is spent.
3. Build project charters
Add a column to your authoritative list called “Signed project charter?”
Check this column only when a signed charter exists and is in a central locked filing cabinet. (Having a cabinet makes it very clear when the column can be checked, and having it locked ensures you have one emergency copy of the charter.)
Create a project charter template, perhaps starting with our free template. This template should be version controlled, and all new project charters should start from the latest template.
Project managers should then fill in the charter for each project, ideally before the project has moved forward to “active.” One simple way to enforce this is to require a project charter before the project review approves making a project active.
For existing projects, project charters should probably be filled in–at least for practice, if not to protect project scope.
These project charters need to be signed by very high level management, such as the CFO and CIO. The charter needs to be as solid as possible. The intention of the charter is to define success, and to protect the project. If someone wants a project to do something and it’s not in the charter, then you don’t automatically do that thing–instead you talk about whether it should be done.
(Aside: if you are concerned you’re building a waterfall model, that’s an excellent observation. A more modern–but more challenging–approach to charters is to define the problem rather than the solution.)
4. Train your project managers
The above steps are intended to provide guide rails to better define what projects exist and what the projects are all about.
However, project managers are the core of project management. They need training. There are some excellent project management training classes out there.
Don’t necessarily look for PMP® prep classes. Many certification classes don’t really teach you hands-on skills. Project management training could be through boot camps, local PMI events, conferences, and books.
This is a good time to think about who in your organization should be managing your projects.
If you haven’t already, consider creating full-time project management positions; project management is a challenging job in itself and it’s even harder to balance when people have other responsibilities, too.
As you’re thinking about staffing, consider that a competent project manager can handle 2-3 large projects. That’s it. But also think about the complications that arise when a project is not managed well, and how much time senior management will save when they can trust that projects are being managed well.
5. Define what a project is by defining what it’s not
Through all of the above, I predict you’ll hear at least once a day, “but what is our definition of a project?”
People really want a clear project definition. At this point in my life at least, I don’t think it’s healthy to have a clear definition. Attempting to write a clear definition results in more people trying to throw work over the wall to project management, and it makes management’s job harder when they say that a small piece of work should be a project.
My argument is to make work a project only when project management is useful. In leading a PMO, I said fairly regularly, “we’ll make it a project to install that door into the doorframe if that’s what people want us to do.” I said that to underscore that an ivory tower definition of project management will clash wildly with reality. It’s not up to the PMO to determine the value of project management.
People may want things to be a project because they start to see how project management controls scope. That’s fine, as long as the project review meetings still prioritize the work against other projects.
So, what work is not a project?
I firmly believe there should be a clear definition of operational work. Operational work is all the stuff you do to maintain existing service: responding to incidents, patching servers, and everything tied up in keeping services running. This work should be relatively easy to define and provides a starting point for conversations about how to make more work operational. Making more work operational is a great goal, because to achieve it your IT service delivery processes must mature.
In addition to operational work, your change management process should be able to handle many enhancements without needing project management. (If you don’t have a change management process, I bet you have a lot of active projects.)
So, projects are the remaining work after operational work and work managed by your change management process.
If you’d really like to dig into defining project management, watch our 2012 EDUCAUSE PROJECT CG webinar, Project management: the process of last resort.