What’s project management? and what do project managers do?

March 18, 2013February 8, 2021 by John Borwick In IT processes, PMBOK 1 Comment

“Who’s responsible for getting the customer’s sign-off for production?”
“I’m not sure… the project manager?”

Project management is the art of taking uncertainty and transforming it into (near) certainty. For a given project, constraints are defined, and the project manager is expected to deliver within those constraints. People mainly think about the “triple-constraints” model of scope, cost, and time, but there are actually six constraints to consider:

• Quality (“Good”)
• Time (“Fast”)
• Cost (“Cheap”)
• Scope
• Risk
• Resources/people

At least in my mind, as long as the project manager is following the project management code of ethics, they are free to use dirty tricks and whatever else is necessary to complete the project according to the defined constraints!

Part of the trick in understanding project management is, people’s visions for what project managers should do vary HIGHLY from one school to the next. Even though there are certifications like the PMP and PRINCE2, which are designed to recognize and standardize project management, people learn mainly from examples. What you see in your organization as “project management” is what you tend to think project management is.

However, the activities of “project managers” vary widely from department to department and institution to institution. Because project managers implement projects within the existing organization constructs, project management will look different based on people’s skills, the maturity of the IT processes, and the organizational understanding of project management. Here are examples of varying (sometimes conflicting) PM job responsibilities:

• Be the walking, talking project scope
• Negotiate project scope with…
  • AVPs
  • Directors
  • Managers
  • Technical staff
• Negotiate and/or manage vendor contracts
• Own the project budget (budgetary authority)
• Track task status/completion
• Send out project communications
• Manage lists of projects
• Prioritize between projects
• Run interference between managers and technical staff
• Own the project management methodology
• Create MS Project schedules and keep them updated
• Collect/track project deliverables
• Explain to people what is going on with a project
• Buy lunch for people
• Accept/take blame

Project management processes do not exist in a vacuum

What’s more, try to define what a “project” is. Yes, the PMBOK provides a definition, but it’s not specific enough to provide a practical test for an organization.

If you have a mature release management process, for example, code changes will probably not be projects. If you have a robust procurement process, then building RFPs and evaluating responses does not necessarily need to be a project. However, I’ve seen definitions like “any work over 80 hours is a project” or “any work costing over $100,000 is a project.”

Project management does what’s necessary to get projects completed, and absent other enabling processes, project management is the “process of last resort.” Project management will get the project completed according to the existing organizational processes, and of necessity the definition of a project will mirror the organization’s existing ability. Thus I will offer the following indicator for your organization:

Assuming work gets completed either way, the higher the threshold for work becoming a project, the more mature your IT delivery processes.

Project managers should not always be subject matter experts

One particular area of confusion is the separation between a project manager and a subject matter expert. Vendors, in particular, have project managers who are also subject matter experts. People see vendor project managers presenting the 5-step implementation plan without consulting anyone, and then laying out the 7 gotchas for each step, and they assume that all project managers should have this level of fore-knowledge of their projects.

The difference is, for those vendors the project managers are selling usually one line of service. Their whole job is to implement the product over and over. University IT organizations, on the other hand, do a little bit of everything: networking, A/V, desk-side support, ERP systems, web sites–you name it. Here’s a simple way to think about whether project managers should be subject matter experts:

The more diverse your organization’s IT services, the less likely project managers should have subject matter expertise for their projects.

Simple solution: when you start a project, name the subject matter expert for the project. If one does not exist, consider contracting for a subject matter expert.

What should project managers do?

The core mental model I use for project management is a contract. Every project needs a contract that spells out the constraints of the project. What is the timeframe for this project? What is the budget? What is the scope? What are the known high-level risks? What are the assumptions–the things that, if they aren’t true, invalidate the contract? What people and skills are needed? This contract, in project management speak, is called the project charter.

So the charter needs to say what should be done, and what’s needed to fulfill the charter. The charter should then be signed by a small number of people who together can provide everything named in the charter. I call this group the “project chartering group” to clarify their role. Ideally this group is at the AVP level and the CIO is one of the signatories.

Project charters should be short.

So, a project manager delivers the project according to the project charter.

How does a project manager deliver a project?

Short answer: the project manager is given a project team to carry out the project. Technically, the project team is given by the project chartering group. The project manager then enables the project team to complete the project.

Again, project management will look very different depending on the organization’s maturity level. However, even at a low level of project management maturity, given adequate time to manage the project the following activities typically take place.

NOTE: this is only a sample of project management activities and is NOT intended to be a complete list.

• Project kick-off meeting: Communicate the heck out of the project charter. The entire project team hears about the project from the highest level possible. What does success look like?
• Mine for organizational knowledge: Look through any architecture specifications, past lessons learned, or anything else to see whether this experience can help inform the current project.
• Stakeholder analysis and communications planning: Figure out who may be affected by the project and how stakeholder groups will be informed or consulted about the project. Identify who’s handling the various communications.
• Project scope definition: Work with the project team and stakeholders to flesh out the project scope in more detail. For example, if the project charter says “develop web site,” what kind of web site? A WordPress site? A Google site? Maturity in business analysis and systems analysis helps here.
• Work breakdown structure (WBS): A Work Breakdown Structure is a decomposition of project deliverables into manageable “work packages” that can be owned by one person. The owner is rarely the project manager. For example, if a WordPress site needs to be created and configured, a member of the project team would own that work package. They become the project manager’s go-to person for that portion of the project.
• Task identification and sequencing: Figure out what tasks need to happen to deliver the work packages. Start looking at interdependencies. For example, does a server have to be provisioned before WordPress can be installed? Does a security review need to occur after WordPress has been installed?
• Risk management planning: Identify high-impact, high-probability risks and plan for them.
• Project scope changes: Project managers follow a defined project scope change process to determine whether the charter should be modified (or even if the project should be cancelled). This process should be risk-based. For example, a small change to the charter might be approved by consent by the project manager and a project sponsor. A big change may require the entire chartering group to approve it.
• Project close-out/lessons learned: At the end of the project, have a party to recognize that the initial implementation is complete. Record lessons learned to be used for future projects.

Your organization’s other processes will improve project outcomes. For example, if you have a formal service transition process, then the project might not complete until knowledge is handed off to the Service Desk, a known error database is populated, and/or the quality of service is at an acceptable level.

Project management should partly pay for itself: up-front planning should minimize the overall project costs. However, project management should also provide value by reducing executive-level “heavy lifting” and by creating governance tools to manage the effort. For example, project management should provide a degree of assurance that a $1 million effort will be complete on time, and it should provide reporting and review opportunities to ensure value is delivered as the project progresses.