Make work a project only when project management is helpful
You can learn a lot about an organization by asking, “how does incoming work become a project?” The answer will fall into one of a few camps:
- “Very low threshold for projects” answer: If it takes over X hours of work (say 40), or more than Y people (say 3), it’s a project.
- “Projects by risk or resource” answer: If it will cost more than X (say $100,000), or last longer than Y (say, 6 months), it’s a project.
- “Looks-like-a-duck” answer: We couldn’t say for sure without knowing more about the work. There may exist a scorecard to guess at whether something is a project.
If they have the “Very low threshold for projects” answer, then most non-trivial new work is a project, so there are a ton of projects. It’s likely project management is not very mature, because it takes a lot of time to manage a project! Proper project management can easily take a week of a project manager’s effort per project, not considering the project team members’ time!
However, it’s likely that project management is not mature because other IT delivery processes are not mature. For example, instead of considering Banner patches to be projects, there could instead be an operational process (in ITIL speak, a “change model”) that’s used to coordinate the people who build, test, and deliver these patches.
If they have the “Projects by risk or resource” answer, that’s a very reasonable answer. However, it’s a possible indicator that project management is seen as a hygiene factor. There may be some audit-related reason that project management overhead is needed–and most people’s goal will be to satisfy that reason rather than to get value out of project management. In other words, project management is helpful in that it reduces risk or cost, not that it adds value.
However, if they have the “look-like-a-duck” answer, that answer is the likeliest indicator that work is made into a project only if project management adds value. It is more likely that project management is seen as a motivator–something that’s worthwhile and should be used. “Projects” are defined more in terms of what project management offers: a charter, a scope statement, a kick-off meeting, a work breakdown structure, a project schedule, a communications plan, a risk management plan, &c.
If project management is perceived as valuable, then you can ask the question, “Is the overhead of project management necessary for this work?” (Aside: If project management is not currently perceived as valuable then don’t help people think of it as overhead. :-)) Do we need project scope control for this work? Do we need a risk management plan?
This approach also requires the most organizational understanding of project management–there needs to be orientation for at least the people making the decision, if not the whole organization, around the value and high-level activities of project management. It can also be the most frustrating method, because it feels arbitrary. Also, work can move back and forth between being a project or not being a project, and systems need to be set up to allow transitions either way.
However, as the organization becomes more mature in its other processes, more work can be made operational and project management can be applied to bigger and more helpful work, targeting the year-long initiatives rather than the month-long initiatives.
Side note: if you are struggling with how to define projects, here’s a quick tip:
Never make something a project so it will show up on a list somewhere.
If the work really needs to show up somewhere, e.g. for your governance groups, just create a second list–for example, a list of “enhancements.” Work should be a project only if project management provides value.