A 30,000 Foot View of a Project Management System

What do you think of when you hear people talking about a project management system? Most people will think about a piece of software or web application that allows a project manager to run a project. The purpose of this project management system would be to assign tasks to resources, manage their activity, and other critical project management activities until the project is closed out.

That’s a correct understanding. However, we’re going to back WAY UP in this article when it comes to talking about a project management system. We’re going to look at the macro-level of project management and how all of the documents, meetings, conversations, activity, deliverables, tangible products and services work together in the project management eco-system.

A 30,000 Foot View of a Project Management System

A 30,000 Foot View of a Project Management System

Input – Process – Output

There are three things that must be present in order for a system to work. These are the Inputs, the Process, and the Outputs. For example, take a car as a very simplistic example of a system. You input gasoline into the engine which converts, or processes, the fuel into the desired outcome of motion (the output).

It’s really no different when you think about managing a project. There are certain inputs (documents, meetings, requirements) that will be processed (teams of people working on these inputs) to produce the output of a final deliverable. This deliverable could range from the finished product that is delivered to the customer, to a work-in-progress that is shipped off to another department for them to complete.

Characteristics of INPUTS in a Project Management System

There are a countless number of items that could be considered Inputs in a project management system. The following examples are two types of Input and what must hold true for each of them:

#1. Documents

There are any number of documents that are associated with a project through its lifecycle. These include business requirement documents, scope documents, quality assurance documentation, and the like. This will require some effort and be snooping around from you as the project manager. This is the area that falls into the category of “you don’t know what you don’t know”, and it’s hard to tell if everything that is important to know about the project and what needs to be accomplished has been captured.

One way of at least getting a sense for this is if you begin hearing a repetitive theme or the same answers time and again to your questions from different people. This means you’ve done a pretty good job of pulling out as much information as possible before you move forward.

#2. Meetings

Meetings, or more precisely, the decisions from meetings, can also serve as Inputs into a project. The trick with the decisions from meetings is that they can sometimes get swept under the carpet or never see the light of day. Your job as a Project Manager at this point is to muddle through all the non-value-add dialogue of these meetings, then get to the core of what really matters and what must be done. This is important to serve as Input into the project deliverables, as it will shape the final outcome. These meetings were held for a reason, and if that reason is not realized by the end of the project it can only mean rework, lost productivity, and pain.

Characteristics of PROCESS in a Project Management System

Once these Inputs have been gathered, verified, and sent along their way in a project management system, they will next be acted upon. If the Inputs are Nouns (documents, meetings, decisions, etc.) then the Process would be Verbs. This is where actions such as Create, Review, Build, Develop, and the other action-oriented words take place.

What is the project manager’s responsibility when it comes to this section of the project management system? This is typically the black-box, “pay no attention to the man behind the curtain” part of the project. It’s sometimes hard to understand what happens in this area as it is filled with subject matter experts and those with enough technical prowess to rival Archimedes.  But, a project manager must know at a high level what processing is taking place on the Inputs that have been provided.

It is the responsibility of the project manager to make sure everyone is dealing with reality, providing realistic dates and cost estimates, and to not get bamboozled by those who may have decades of experience in one particular area. The only way this can be accomplished is to gain the trust and respect of these experts. How do you do that? Make their lives easier. Clear obstacles, help them focus, make sure you have accurate INPUTS into their PROCESS and end products don’t come back for more work. Respect their time, push back when necessary, and always work in a spirit of partnership rather than an  “us versus them” mentality.

Characteristics of OUTPUT in a Project Management System

And finally, there is the finished product. After each department or group has acted upon the Inputs and provided value via their Process…this is the result. The finished product can be something that is delivered to another department to put their unique signature on (for example, a version of a software package going from the Development team to the Quality Assurance team) or can be the finished product that is delivered to the customer (for example, a building that has been completed).

Regardless of the final product, it is your role to make sure the original requirements of the project have been met and that scope has not ballooned out of control.

This is the epitome of the 30,000-foot view of a project management system. At its core it consists of somebody putting something into the machine to be worked upon, the value being added to that input and a final, useful deliverable coming out on the back end as output. Input – Process – Output. If you view your projects that way at a macro-level you’ll be able to move mountains.

Leave a Reply