Project Management is a difficult subject because projects come in so many shapes and sizes. A project often entails fitting the proverbial round peg in a square hole while using a very diverse group of people with vastly differing creative ideas. Therefore projects are not only about multitasking but about problem solving, and often includes managing others. Many projects fail to reach expectations or even end in total failure. Managing projects are difficult but every manager will sooner or later participate or even lead a project. Let’s discuss the requisite approach to project management in an attempt to eliminate many of the reasons for less than satisfactory results in project implementation.
A project as defined here is a temporary role assignment which is deemed to be best handled outside the normal hierarchy of the organizational structure and falls outside the established roles of the organization. While many of the same project management concepts may apply to roles that have been titled “project manager” and are a permanent part of the org structure, I am writing here about temporary projects which are understood to have a real or implied completion date. Therefore the individuals selected for the project are moving to this new project role on a full-time or part-time basis, but with an expectation of returning to their previous manager fully after completion of the project.
Projects come in various levels of complexity of work, with “work” being defined as “the use of discretion to deliver a desired output.” A project to put together a playground set for a children’s play area is clearly less complex than a project to start-up a chemical plant. Therefore one important first step for the project sponsor is to clearly define the project. The sponsor is the person who is ultimately accountable for ensuring successful completion of the project by selecting the project manager, assigning the project manager the project goal(s), and setting the boundaries. Obviously this would be an appropriate time to use a CPQQRT as described in Post 7, Task Assignments.
After the sponsor has a picture of the level of complexity of the project and has written the CPQQRT, he/she must select a project manager (PM). This selection should be based on the work required of the manager and not necessarily the technical expertise which may be needed on the project team. Certainly a minimum criteria is for the PM to have the level of work ability (LoWa) needed to manage the complexity of the project (see Post 4, Hiring and Evaluating Employees). A common mistake is to base the PM selection solely on knowledge, skills, and experience (KSE) because of the technical nature of many such projects, without regard for the complexity and/or the appreciation for the management skills needed for this role. Upon selecting the PM, the sponsor should spend appropriate time with the PM to review the project expectations as written in the CPQQRT and assist the PM in selecting the team members. Remember the PM has VARI authority (see Post 3, Defining the Role of Manager) including veto power over any selection to insure and maintain his/her accountability for the results of the project team.
Since my definition of project is a temporary role assignment on a full-time or part-time basis, the VARI authority needs some further explanation in regard to Review, Recognize, and Reward. Each member of the project team has been authorized to work on the project by their original manager and he/she expects the project team member back in full swing in the previous role at some future date. Therefore the original manager remains accountable for the employee in an overall sense while the PM has accountability only as it relates to the project. Since the original manager is also accountable for fairness and consistency across a broader group of direct reports, which may be carrying extra work assignments while the project team member is on the project, the PM should review all project team member as it relates to the project only and coordinate with the original manager regarding full Review, Recognize, and Reward actions.
Now that the full project team is in place and VARI authorities are understood, its time to get down to successfully completing the project. In many organizations, a process has been established for executing projects such as Six Sigma, Kepner Tregoe, and many others. These standard methods allow for training, use of exceptional tools, more effective team-working, and the ability to develop highly refined project management skills. When numerous projects are done of similar sizes and shapes these project management methods are highly effective and should be refined and used as a standard part of the organizational toolbox. If you have a large project or are not able to take advantage of a standard method, I will offer some basic concepts in project management for you to consider.
In my first management role I was production manager of an operating unit in a chemical plant complex. It was decided to expand my unit by building another one beside it. The units would be separated by a warehouse but were similar in design except for newer equipment and controls. Since I would manage both facilities after completion, I was designated as Start Up Manager of the new unit. Having heard horror stories about start-ups. I found a training course in Houston, Texas and attended a training called Process Plant Start-ups. Most of what I know today about project management was derived from the vast array of knowledge offered at that course. Fear of failure can be a big motivator and I was very aware of the importance of this start-up and my lack of experience in projects this large. I took notes and hung on every line of our very knowledgeable instructor.
The essence of project management is making lists. Lists are powerful tools which I hope you already have experience using, such as the To Do List. There are many types of lists and many ways to use lists. When I returned from my training, Idid as suggested by the instructor and gathered the most experienced chemical plant experts in my company in a room along with the construction team. From my perspective many of them were old and crodgedy and I was surprised they even accepted an invitation from a young inexperienced manager like myself. I asked them a simple question to start: “What can go wrong in a start-up?” In a few moments I had a list. Then on to the next question: “How can I prevent these problems?” By the time the meeting ended I had the beginnings of a plan. (Did you know that a plan is just another name for a list?) I also had some old and crodgedy experts on my side, and ready to help. Most people are willing to help someone who asks questions and wants to learn.
One list in the plan was something called the “Equipment Criticality Study”. My team and I made a list of every piece of equipment being installed in the new unit. From that list we made a one page check list of each item, detailing how we would check each item before the introduction of the first chemicals. The main reason was to prevent problems and insure the equipment would operate correctly at start-up. Some items were checked before and during installation and others were checked at a point closer to the actual start-up. We incorporated into the study all the learnings from the experts in my initial meeting. I could tell you some wild and crazy stories about what we found and problems we prevented by doing the Equipment Criticality Study, but I will save it for another time. (Invite me for coffee and I will be happy to tell story after story.)
My instructor had 2 philosophical statements which I adopted as my own: 1. Never leave something to be done during the pressure of the actual start-up if it can be done ahead of time and 2. Prevent as many problems as possible so you have time for the unexpected problems which will happen at the worse possible time. I not only adopted these statements for myself but I tried to insteal them into my start-up team. In choosing my start-up team I pulled from the existing operating unit. I wanted experienced members and I was fortunate to already have a similar unit in operation. We started early in staffing the start-up allowing time for replacing each member in the existing unit. I also leaned heavily on one of my engineers, assigning him the task of Start-Up Engineer and making him my backup for the project. When the start-up team was fully staffed I pulled everyone together and asked them the question: “What do we need to do first to start-up this chemical plant?” As expected someone shouted out, “push the start button.” I had placed sheets from a large rolls of chart paper on one wall, so I wrote “push the start button.” Before I had finished writing, the conversation went like this. “Wait a minute! You need to do water testing first. How about utilities like electricity, air, water, etc.? Don’t we need to check them and turn them on? How do we know safety equipment is in placed and that we have been properly trained?” And the conversation continued with each person deciding that something needed to be done before the action previously suggested. Soon I had added more and more chart paper as I moved backwards around the room to capture their comments. Eventually I had returned to the wall which had “push the start button” which meant all four walls were full of actions to be done before pushing the start button. Everyone was amazed that so much needed to be done prior to pushing the start button, but we also discussed how some things need to be done in an order or before or after other items. Before long we had a wall with a brown paper Gantt Chart done by hand using black permanent markers.
A Gantt Chart is an important type of list. It is used to identify the time required for completion of each item on the list and the critical path. The critical path is the items that represent the minimum time path by which the full project can be completed. I used this Gantt Chart to communicate to my management the expected time frame when the start-up would be complete with the unit producing at design capacity. My team used the original Gantt Chart, done by hand and engaging the full team, to communicate with each other. In this circumstance, our team was divided into four shifts to cover the start-up over a 24/7 period. Each item on the chart was being completed by a shift while the other shifts were away. Each shift used a colored marker to indicate that the next items was in progress or was complete. The Gantt Chart makes it easy to do the items in the correct order and to communicate the status to others.
And now for the unexpected. With all of our lists I was getting more and more confident that we might start up on time and without major problems. Our Gantt Chart showed that we expected to “push the start button” on January 24 or 25, and the team was doing a super job ensuring everything that could be done was done before that date. Things were so great that I decided to take a hour out of the morning of January 24 to go with my pregnant wife (due date in March) to her scheduled doctor’s appointment. Long story short, the doctor told us we should proceed immediately to the hospital for the birth of our first child. Some time during the morning I checked in with my Start-up Engineer. He said the water testing was going well and we would truly be ready to push the start button in a few hours. We agreed that I would stay at the hospital and he would proceed and manage the start up. The start-up proceeded without incident and in the days ahead we were able to bring the unit to design capacity right as planned. In addition to having a beautiful and healthy daughter, I was congratulated numerous times for the “best start-up in company history” to that point. The company adopted the concept of lists as described here and the next major start-ups followed my template, experiencing similar successes.
Comments are closed