Before we can succeed as project managers, we have to understand what it is that we’re actually tasked with managing. We literally can’t be successful unless we know what the definition of success is.
At first blush, this sounds easy. As PMs, we are tasked with planning and overseeing the creation of some new unique "deliverable." This deliverable is essentially the product or service or big-picture objective that will be the tangible outcome of a project. For brevity's sake, let's call it the “widget” that is going to be built. This can be almost anything, from a modest home addition, to a race car development effort, to an ambitious new software application, to an upgrade to an operating system, or the design-build of new billion dollar supercollider—it doesn’t really matter. The job of a PM is to ensure that all the tasks required in the creation of the widget occur on time and within budget, and the resulting product performs the way it was intended to perform. Simple, right?
Well, yes and no. While the creation of the unique deliverable is obviously the core raison d’etre of a project—and therefore should be the core focus of its project manager—there are a number of supporting tasks that also have to occur both sequentially and in parallel with its construction to ensure the project’s success. There are also always constraints—both internal and external—that dictate how and when the project can be brought to fruition; these can be fixed budgets, hard deadlines, required personnel, and so on. Said another way, every project’s specific deliverable may be different from the next, but all projects share common generic attributes, functions, constraints, and tasks that have to be managed in order for the widget to be created—and hence the project to succeed. This in fact is fundamentally the role of a project manager: to plan, execute, monitor, control, and ultimately ensure completion of all the discrete tasks and efforts that will lead to the creation of the deliverable/widget within the constraints and restrictions imposed.
So what are these common tasks, efforts and constraints? To fully answer this, we need to rewind and start with what the formal definition of a project is. I’m a certified Project Management Professional (PMP), so naturally I am inclined to turn to the Project Management Institute (PMI) nomenclature, where a project is defined as:
“a temporary endeavor undertaken to create a unique product, service, or result.”
Other organizations have slightly different, but fundamentally similar definitions. For example, the highly-regarded British Standards Institute (BSI) defines a project as:
“a unique set of coordinated activities, with definite starting and finishing points, undertaken by an individual or organization to meet specific objectives with defined schedule, cost, and performance parameters.”
Uh, okay, you might be thinking. What’s so earth shatteringly useful about these stilted definitions? Well, for starters, from these descriptions we can tease out those aforementioned key characteristics that all projects share in common. These in turn will lead to a core defined set of tasks and responsibilities that us, as project managers, will be responsible for organizing and overseeing during the construction of our respective widgets. It will also help us prioritize the work we have to do to accomplish these goals. So let’s break down the definition of a project to see what its constituent parts are and ultimately tells us what it is we have to manage. As it turns out, there are nine specific areas or core functions that you as a PM need to focus on:
- Deliver the Widget. First, there is the unique deliverable itself. We’ve been informally calling this the “widget”, but "deliverable" is the more correct word. In fact, perhaps a better term might be the project’s over-arching "objective" or "goal." I personally like these alternate terms, as they leave open the possibility of creative technical solutions that still meet the customer or end-user's needs. In a bridge construction project, for instance, the design solution might ultimately be, in fact, a steel suspension bridge, but the objective is the more broad goal of providing a transport system that allows the movement of people and vehicles from one side of a river to the other. It doesn't specify the actual solution, which could be the bridge, or might be just the purchase of a ferry, which could cost a lot less money and meet all the requirements. But I digress.... the bottom line is that the deliverable is something new and discrete you are tasked with providing that has never been done before in exactly this same way. It is in fact "unique." If you don’t deliver this specific thing by the end date of the project and/or when the money runs out, you will have, by definition, failed as a project manager. When managers speak of “keeping their eye on the prize,” this in fact is the “prize.” At the very heart and center of managing a project is the need to define and create the deliverable.
- Manage Scope and Quality. Second, because the deliverable is unique, it will by definition have very specific attributes associated with it. If you’re building a physical thing, these attributes are usually specified by the form, fit, and functional needs of the deliverable. If it’s a software upgrade project, the attributes may be performance requirements or specifications for the graphical user interface (GUI). If it’s a new scientific instrument, the key attributes of the finished device are likely its technical science requirements. And so on. Regardless of what the deliverable is, we can divide these attributes into two related parts: scope (i.e., what precisely will and won’t be created) and quality (i.e., how good will the delivered scope perform). Note that these attributes are measurable, or testable. In other words, final project success is significantly defined by how closely your team creates a widget that literally functions and performs per the predefined scope and quality requirements set forth at the beginning of the project.
- Manage the Schedule. The various definitions of a project also always state that projects are temporary in nature. This means every project has a start and an end. Said another way, every project has a definitive beginning and a specific target end date, which in PM-speak means it has a schedule. Now, often the date of a project’s beginning may be somewhat fuzzy as an idea evolves into a true project and gains actual funded momentum. The end, however, must be clearly defined so that all the project participants agree on what it means to be complete. A project’s success is often determined by how well the PM does in managing the schedule and meeting the delivery date for the final widget.
- Mange the Cost. Besides Quality and Schedule, adherence to a Budget is a fundamental measure of how well a project is performing. (In fact, these three things together are often referred to as the “triple constraint” or “golden triangle” of project management: good, fast and cheap.) Someone—often the customer or sponsor or upper management—has agreed to commit financial resources to allow the creation of the widget to proceed. The project manager is tasked with allocating and spending this pot of money in a way that allows the creation of the widget to occur efficiently and in the proper sequence. If you overspend this budget before you finish, the project is typically viewed as a failure. The PMs job is to ensure this doesn’t happen.
- Manage Risk. The word “unique” in the definition of a Project also implies some measure of uncertainty. In other words, by definition, no one has created this exact thing before, so there is risk of unknown problems derailing or slowing or costing the project. This risk often spans the golden triangle of scope/quality, schedule, and cost, but it can also extend further into things like loss of personnel, external project factors, stakeholders, change, and the like. One of your key jobs as a PM is to identify, mitigate, and manage these risks that threaten your project.
- Manage and Control Change. Upper management and sponsors/customers hate to hear this, but the hard fact is a project plan is nothing more than a series of educated guesses as to how the work will unfold with time. And as military strategist know, no battle plan survives its first contact with the enemy; i.e., your management plan will change. External and internal factors will morph the project. Technical hurdles will arise. Customers will ask for new features to be included in the widget. Key personnel will leave. Contractors will fail to deliver. You will have to adapt and modify your plan to accomodate these issues. In other words: change happens-- deal with it. Said simply, one of your jobs as a PM is to manage this inevitable tide of change in a way that minimizes the effect on delivery of the widget.
- Manage Procurements. At the end of the day, you have to actually create the widget. This means you have to “procure” it and its constituent parts. This procurement can be via contracts with contractors, purchase orders with vendors, or perhaps the bits and pieces of the widget are to be fabbed/created in-house by your project team. Regardless, one of your key jobs as a project manager is to ensure these procurements occur in the correct order, on budget, on schedule, and that the delivered scope/quality is up to the appropriate standards. This in effect is where the rubber of the golden triangle hits the management road.
- Manage the Stakeholders. Ah, stakeholders. Love ‘em or hate ‘em, these are the organizations, groups, and/or individuals that will impact and/or be impacted by your project. For example, the “unique product, service, or result” that is your widget is being paid for by someone-- and that someone cares and often wants to be in decision loops—or least informed of project progress on a regular basis... or else they might decide to stop supporting the project. Similarly, there are customers who will use the widget once delivered, and these people often have strong opinions about scope and quality and schedule. There can also be government regulatory entities who have a say in how you can procure the widget, trade associations and unions that want a piece of the pie, interest groups who want you to succeed or fail, suppliers, lenders, senior management, etc. that all have a stake, big or small, in your projects’ success. How you identify, monitor, communicate/inform, manage, and ultimately satisfy these stakeholders can have a huge impact on the perception of whether your project succeeds or fails.
- Manage and Lead the Project Office/Team. Lastly, but certainly not least, is the management of the project team/office that will perform the day-to-day work and ensure delivery of the unique widget on time and budget. Technically-speaking, the project team is a subset of the aforementioned Stakeholder group, but it is so fundamental and unique to the success of a project that I believe it should be treated as a standalone management entity. This project team can be just 1-2 people, including yourself, or it can be a cast of hundreds or even thousands. Your leadership of this disparate group is fundamental to your project’s success; i.e., these people are the heart and soul of a project, and everything from their technical abilities to their health and morale are factors that can and will ultimately affect the delivery of the widget. Managing this team is one of your key jobs as a project manager.
- [Bonus PM Function: Communicate. This one is a really important but under-sung function of the project manager. It also takes on many, many different forms, from formal reports to informal telephone calls, and everything in between, including meetings, emails, document repositories, task lists, and the like. Because it's so broad in nature, and because it stretches across so many of the previous nine PM functions/jobs, I don't include it formally in the list of core functions of the PM. But it's still vitally important. So consider this a bonus thing you have to master and perform for your project to succeed. :-) ]
© Copyright 2015 Mark H.Warner. All rights reserved.
No comments:
Post a Comment