One night last November, I was driving home to Sylvania, Ohio from Indianapolis, Indiana. It had been a tough day, the project was going OK, but there were so many external factors that needed to be factored-in as the risk was quantified. The rain started to fall as night came early. I popped a cassette into the player and kept driving. The music of Meatloaf started to bring back memories from my youth and I soon found myself placing the problems of the day within the songs of the past.
For those of you not familiar with this artist, Meatloaf was a popular singer during the late 70s who enjoyed a strong resurgence in popularity during the 1990s. Meatloaf had a certain “theatrical rock” style that combined very passionate lyrics and music with some of life's daily problems. I suddenly found myself starting to compare my project management issues with the songs drifting through my cassette player. At that time the idea for this paper started to develop. I decided it would be a very interesting retrospective to combine my experiences through the years of project management with the various songs that were performed by the artist Meatloaf.
The document takes a title from a published song and decomposed it into different subcategories. First it takes the song title and maps it to a specific aspect of project management. It then provides some insight identifying whether or not you are a candidate for this experience, and then some tips on what to do when you're there and finally some ideas on how. Finally, some ideas are presented to prevent you from ever getting there in the first place. So buckle in, crank the stereo up, and let's look at a philosophy of project management according to Meatloaf.
“I'll Do Anything for Love, But I Won't Do That”
When I hear this song, I think of all the challenges associated with scope creep and change control. As the project unfolds, many opportunities present themselves that challenge the original project objective or project requirements. It might be the customer that says: “if you have this feature—I'll buy more” or the programmer that says “as long I'm in the code I can make that change easily” or the “I thought it was going to do that instead of this!” Regardless of the circumstance, the Project Manager is going to be put under extreme pressure at times to make changes.
Project Management Aspect
The PMBOK® Guide has many components regarding Change Control. There are also several packages available to help manage change control, it's not the mechanisms of change control that are important here, but the consistency, rapid responsiveness, and communication of the changes to the team.
One of a Project Manager's greatest challenges is the proper way to say “No” to a project champion or a very influential executive. Many times the Project Manager feels they don't have the authority to reject requests, but should somehow make the request happen. The answer needs to be stated in terms of impact to the project in areas of cost, time, scope, or product consistency. The manager cannot make change commitments over a phone call, but instead needs to insist that a process be followed that identifies the definition of the change, the reason for the change, and the possible impact of not doing the change. Present the results of the analysis to the requestor, which will lead them to a decision as to whether or not the change is justifiable.
How You Know You're in Too Deep
• A participant starts a conversation with “Can you do me another favor?”
The Project Manager must first insure the project is baselined in budget, requirements, and scope. As soon as the baseline is complete, strict change control must be enforced. Even if the change is as simple as changing the name of a field on an input screen. Doing favors at the beginning rewards avoiding the process and starts the Project Manager down a path of “under the table” project mismanagement.
• Not all members of the team are aware of the changes.
How many times have you heard: “Oh so-and-so said on a call last week that we're no longer supporting that in this project”? Or a team member says: “I never knew that's how this was being done? When you start hearing phrases like that, the change control is out of control.
• The process is circumvented.
The last place a Project Manager wants to hear of project changes is during a status meeting. If a member of the team has agreed to a change that isn't identified in the change control process then the Project Manager must take swift action. Both the requestor and the doer need to be reprimanded for “circumventing the process.” The Project Manager should insist that the item, even if completed, still needs to be put back into the change control process.
• If every item is a “Severity One” then nothing is number one.
Some times a sponsor will learn that by hyping the severity of a change, it is more likely to get accepted and enacted. When the only items that come into the change control are severity one, then you can be assured you're not getting all the items that are coming up.
• There are changes in the deliverable that aren't in the requirement documents.
This can be a big problem in development projects. A user may call directly to the programmer and say “Can you do this” and it's done. This invalidates all steps in the development process and will render all support documents and test plans suspect.
Prevention
• Well-defined change control process
The challenge for a Project Manager is to make the change control process useful, simple, and effective. Either extreme (no process to a very bureaucratic cumbersome process) will spell failure for managing the project. Three items that need to be in all change control processes are:
- Method to submit a change request
- Method to evaluate change request
- Agreement to the changes (Scope, schedule, deliverables).
• Prevent creep
This one is easier said than done. The Project Manager needs to keep an active list of “Parking Lot” issues and future enhancements list. This insures that items are not forgotten and may actually drive the people who want the changes to present them as items for the future.
• Don't let “little favors” circumvent the process
As soon as the project is base-lined (and maybe even within the requirements development process) start to insist all changes no matter how big or small are documented in a change control.
• Regularly schedule change control evaluation meetings
It is imperative that people are aware of change requests and their status. The Project Manager cannot let changes fall into a “black hole” where no status is ever given. That will encourage circumventing the process. A regular meeting where the evaluations are discussed and the results identified will reinforce the change control process and increase its effectiveness.
Summary
It is essential to have the change control process in-place at the beginning of the project and to stick to it. Many times, managers let “little changes” slide through at the start and find themselves in the position of having to become stricter later on in the process. Change control has a somewhat “Darwinian spirit” about it. Only the strong changes will survive and the weaker and less important ones will not make it. An effective change control process will keep the team focused.
“Where the Rubber Meets the Road”
This song is an examination of where theory meets reality. This is the nuts and bolts of day-to-day project management. One of the biggest challenges facing the Project Manager on a daily basis is the identification, communication, and resolution of various issues that can impact the final project deliverable.
Project Management Aspect
Issues are those little things that hang around and need to be answered and communicated throughout the project team in order for certain tasks to be completed and the project to move forward. Some of these issues have a direct correlation to a task on the work breakdown structure (WBS), while other issues regard policy, philosophy, and direction of the project. Issues differ from change control as it may apply to interpretation of a requirement or an addressing of a technical issue that is not included in a functional requirement. Issues may also include things that do not directly affect the specifications of the project but may affect the schedule or the team's ability to meet the “plan.” An example may be a building power outage, a new operating system upgrade, or a scheduled move from one office location to another. These issues need to be addressed throughout the project.
How You Know You're in Too Deep
• Not all members know what changes are going on
This was talked about in the previous section but it applies in issue management. Lots of time can be lost if the issues are not communicated and their expected impact quantified.
• Issues never get resolved—they just linger
We have all been on projects where some issues just never seem to go away. Even if there is a “resolution” some team members want to continue revisiting them. The project manger must keep the team focused on the project and communicate the fact that a decision was made, right or wrong, and we need to go forward with that decision.
• Members have made changes due to a “phone call” or a “water cooler conversation”
This item was also discussed in the previous section, but involves issues other than scope or change control. For example, a test environment may be planned for machine B and then a late night discussion moves it to machine C. Only two programmers know the change and nobody else does—another communication problem.
• Module “Interfaces” are not well defined
In the book “The Deadline” Tom DeMarco discusses how most problems in a system involve the interfaces between modules, not problems within the module itself. Issues resolve when team members do not effectively document or define the inputs and outputs of a module and how it interfaces with other aspects of the project. This item is not confined to IT projects. A manufacturing project can also have these problems.
• People don't know all the “procedures”
A Project Manager cannot manage all the functional organizations that make up the project teams. However, if the Project Manager notices that there is misunderstanding of some sub-processes within an organization, he can raise that as an issue and assign the functional manager a task that all members of their team be “trained” in that subprocess.
Prevention
• Central repository of issues with the resolutions
In order for issues to be understood they must be communicated. There should be a central repository of all issues with their resolutions, open and close date, and assigned responsible party.
• Regularly scheduled status meetings
This can't be stressed enough. A regular status meeting with a defined agenda that focuses completely on status is critical. The project manger may want to “rotate” topics so not all team members are involved in the entire meeting. Issues can only be closed at status meetings.
• Set severity levels
Any issue that exists needs to be set with a priority of 1 (high) 2 (medium) or 3 (low). Although some cultures are successful with more layers of definition. A severity level helps prioritize which issues need to be addressed first.
• Do “Lessons Learned” when issue is solved
This is my personal bias and actually you will see reference to this point throughout this paper. If there is a well-defined repository of issues that affect the day-to-day flow of the project, then there is a blueprint for defining all the lessons learned. The easiest time to capture the lesson learned is when an issue is resolved or closed. Why not include a section in the resolution of the issue that includes “Lessons Learned”?
Summary
The rubber meets the road in the day to day handling of issues within a project team. Issue management includes identification, resolution, and communication. Communication exists in both having team members identify the issue and also providing input to its resolution. An effective Project Manager will be able to transition theory into reality and be able to dig into his toolbox and apply the appropriate tool at the appropriate time to the specific problem.
“Objects in the Rear View Mirror May Appear Closer Than They Are”
There are many different areas of project management to which this particular song applies. I was thinking it might apply to schedule daemons or competitive pressures or even loosing people to other projects, but I decided to apply it to the concept of risk even after something appears to be completed. The experienced Project Manager understands that even when something is completed, you still can't sleep at night and just have a “gut feeling” that there is still a potential for problems. This song has the following lyrics, which has impacted so many projects:
“And though the nightmares should be over
Now some of the terrors are still intact
I'll hear that ugly coarse and violent voice
And then he grabs me from behind and he pulls me back.”
Project Management Aspect
Risk factors in a project are always present. Risk mitigation cannot only occur at the beginning of a project, but must be carried through the entire life of the project. In issue management and change control, the selected course of action poses both opportunity and risk. The experienced project manger knows to factor in these consequences in subsequent tasks even after an issue is resolved. In other words: be prepared that an issue that appeared to be over might come back—and with a vengeance.
How You Know You're in Too Deep
• Solution has not been verified
One of the easiest traps a project team can fall into is to assume the solution is adequate because of the results of initial testing. Do not announce the problem is over until it is completely verified. This trap is much more evident if the project complexity is great and there are many components in the final environment.
• Only “small problems” left
Beware of the message that says its working fine but there are only a few small problems left. People who suggest or implement a solution may be overly optimistic and others may be overly pessimistic. However, the only small problems are an indication that the object in the rearview mirror is not completely behind you.
• Blame shifted to another party
This occurs when the words come out that our problem is solved, but the other group needs to make such and such a change. The project manger needs to keep the risk aspect of the entire product ecosystem in mind. Beware of words such as the application works fine; it's the network that has the problems.
• “Double Speak”
When you get double negatives and answers such as it's mostly working properly—raise that caution flag. For example in an IT project the process may now work, but the time is extremely slow.
Prevention
• Complexity Assessment
This paper has mentioned a product ecosystem. A complexity assessment helps to quantify all the components of an ecosystem and how the product interacts with them. The more complex the ecosystem, the more likely there are components that can be “that object in the rearview mirror!”
• Problem identified and resolution defined
The fundamentals must be in place. Requirements should be able to define lower and upper limits, problems and issues should be identified and the results of any change should be documented and expectations defined.
• Quantifiable results
Don't accept a problem as resolved until it can be quantified. This should be in the resolution expectation or in the requirements definition. If the results are outside the parameters, but seem to be acceptable, then the change control process should be evoked.
• “Plan adjustment” well defined
As mentioned above, the expectations must be well defined.
Summary
The Project Manager must be aware of risk factors throughout the life of the project. Solutions to issues and change control impacts introduce new risk factors that the Project Manager should mitigate.
“Two Out of Three Ain't Bad”
Like some of the other songs in this little analogy, there were many aspects of project management that can be applied to this song. For the purpose of this document, I decided to use the example of tracking tasks in relation to the schedule. One of the problems with chronic project mistakes include the inability to correlate the WBS with the schedule and how much in-line or out of line they are. The results are that tasks aren't being completed, the people may not even be working on the WBS tasks or the project focus is completely lost.
Project Management Aspect
One of the major aspects of project management is to be able to determine the project status in relationship to the original schedule. The PMBOK® Guide has several guidelines on defining this relationship. This section will look at ways to break down the schedule into small “time boxes” of two or three weeks and keep focused that the tasks can be completed in that time box.
How You Know You're in Too Deep
• Tasks being worked are not reflected in WBS
The project team may be working on tasks that were brought about by the change control process and were never reflected in a revised WBS. The completion of tasks is so far behind that due dates that past weeks ago are still being worked.
• Calendar too far out to comprehend
The project schedule has never really been broken down into manageable time frames and tasks are at such a high level they can never really be comprehended. If a person has no defined deliverables for a few weeks, it's hard to focus on the task.
• Too many deliverables for an individual in a short time frame
The opposite end of no deliveries in a realistic time frame is that there are too many deliverables with the same week for an individual.
• High defects and lots of rework
The members of the team are spending a large majority of their time fixing defects from previously completed tasks and are not able to work on the new tasks assigned to them.
Prevention
• Items due this week in status reports
The calendar and tasks to be worked should be very short-term oriented and focus the work accordingly. The Project Manager can focus the team by placing the items due to be completed that week in the beginning of the weekly status report. A daily email with items completed yesterday, items due today, and items due tomorrow will keep focus.
• Tasks broken down into a manageable level
The tasks in the WBS need to be defined in small logical time blocks.
• Rolling Wave Planning
Greg Githens, PMP, presented a paper on Rolling Wave Planning at PMI 1998. This technique is very useful in defining deliverables in a short time frame and including a task of re-planning as part of the “wave.” As the project rolls into the next “wave” a new set of expectations and deliverables is defined. This technique includes a combination of the project scope, WBS, and deliverables with the current status of tasks completed and allows the team to focus on the short-term tasks.
Summary
The concept of Rolling Wave Planning helps focus the team on tasks in the short term. It also allows a much better opportunity to factor in change control and issue management modifications to the project.
“Paradise by the Dashboard Light”
Almost every project has a honeymoon at the beginning. Things are bright and rosy, enthusiasm is high, and expectation is high. This song has a stanza that states: “It was long ago and it was far away and it was so much better than it is today.” Sometimes project team members get disillusioned and start going through the motions.
Project Management Aspect
Almost every project has a honeymoon at the beginning, things are bright and rosy, and it can all be accomplished and come in under budget and ahead of schedule. Are the sponsors wearing rose-colored glasses and are their expectations too great. Will the team be “together for the long haul?” What can a Project Manager do at the beginning to provide a realistic plan?
How You Know You're in Too Deep
• Talk of “remember when” or “I thought it….”
Sometimes the Project Manager needs to make himself available to listen.
• People leaving the project
There is always turnover in a project, if the turnover seems high, that may be a sign that the project manger needs to use some “people skills” to reenergize the team.
• High Defect Rate
If the number of defects per tasks is higher than normal, that may be a sign of burnout.
Prevention
• Set realistic expectations at the beginning
Start out the project with realistic expectations and responsibilities of the team members.
• Issue Management and Change Control
The benefits of this have already been defined. Proper implementations of this aspect of project management will keep the project from getting way out of control.
• Program Plan—how does this work in with other projects
Don't keep the project in isolation. Have discussion with team members how this project fits into the corporate program. Help them to realize this is a resume builder and their attitude and enthusiasm will help them make it through the tough and difficult times.
Summary
Schmooze ’em. See my presentation from PMI 2000.
“You Took the Words Right Out of My Mouth”
This song is here to state that the author is sharing observations of years of project management. Each project manger has their own definition for correlating the philosophy of Meatloaf to Project Management. It's all up to the interpretation of the individual.
