Debacle: Case Study of a Small Project

Posted on May 16th, 2013 in - Kathy Martucci, Constraints, Lessons Learned, Project Management, Projects, Requirements, Scope | No Comments »

by Kathy Martucci, PMP

Picture this: a roomful of disappointed and barely civil executives are intently focused on you.  The one-page briefing you have prepared seems woefully inadequate to answer their questions and address the situation. It’s embarrassing, humiliating and perhaps career-ending.

At this moment, you are asking yourself why you chose project management as that career.

Rewind: four months ago.  The same executives gather with smiling, relaxed faces to discuss an initiative that appears, on its surface, to be a quick hit. #1 Executive has promised a live demonstration of the deliverable to The Board at its annual meeting in 3 months.

No problem.  Plenty of time. Shouldn’t take too much effort. The Board members will be so impressed they will no doubt vote in our favor for the funds requested. Oh, we know you have “those other” projects in play. You are such an accomplished project manager; you can do this part time.

In spite of your misgivings and a nagging little voice in the back of your head, you (of course) take on the project. After all, the last time you looked, #1 Executive is at the top of the organization chart.  And you aren’t.  And this is “just” pulling together something that is already there.  “Just” jot down the tasks needed and get going.

In three weeks, there are so many questions about scope, the team (ok, one PTP – part-time programmer) is at a virtual standstill.  You request a meeting of the stakeholders, but #1 Executive is preparing the financial statements for The Big Board Meeting.  You can’t get on the calendar.

In four weeks, PTP leaves for a month-long visit to his family whom he hasn’t seen in 2 years. You resort to engaging the junior programmer who needs at least a week to get up to speed.

In eight weeks, a brief sit-down with #1 Executive gives you insight into the composition of the (real) final deliverable.  But this time you speak up: It’s unrealistic that the ideal could be delivered in another month, especially to so critical an audience.  Let us go back to the office and rework the requirements. We will meet in 2 days to present what we CAN deliver.

In 2 days, #1 Executive is unavailable to review the new deliverable. You and the PTP go down that road anyway despite lack of direction from the top. In a week, when you finally do meet, #1 reluctantly agrees to the reduced scope.  Frown lines begin to appear.

You get the picture. At the Board meeting, the demonstration goes poorly and the Board members are less than impressed. #1 Executive loudly and clearly blames the project manager and leaves without the necessary funds for the pet initiative.

Back to the Future: the post-mortem.  The case above contains so many pitfalls of managing a small project it’s difficult to pinpoint the #1 mistake.  So, let’s focus on lessons learned.

In the future, you strongly suggest that the organization will:

  • Establish quantitative criteria for small, medium and large projects
  • Use the criteria to recognize when the organization is about to engage on a project
  • Ensure better support and participation of executives in small and medium projects
  • Use an approved, scalable framework to ensure adequate planning of all projects
  • Proceed to the execution phase of a project only after passing a planning gate

These are high level guidelines to address shortcomings of the Project Management Methodology employed at the organization especially for smaller engagements. Can you identify the specifics of the case that led to the Debacle?


Managing Large Projects or Programs

Posted on May 7th, 2013 in - Bruce Beer, Best Practices, Budget, Communication, IT, Lessons Learned, PMO, Project Management, Reporting, Resources, Schedule | No Comments »

By Bruce Beer, PMP

OK – you have been asked to manage a new major project that is an integral part of your company’s strategy (or your customer’s strategy if you are providing project services) and the cost is estimated to be in the 8 to 9 figure range.

Where do you start?

A very large project would probably be a program (a group of related projects) rather than one single project, so you would probably need a Program Management Office – PMO – to manage this juggernaut. I would suggest that in most cases you would start with the PMO management infrastructure. Assuming you are to be the program manager, on a major program you will probably need a deputy to help with the workload and cover for any absences you might have.

I have worked in two different types of programs in the $300m to $500m range. One was global, one was domestic. One of them included individual PMs as part of the PMO; the other just included the key PMO functions and did not include the PMs in the team. My experience leads me to believe that the former – PMs as part of the PMO team – is preferable, so I will use this assumption for the rest of this article.

Let us look at the makeup of the PMO for a major undertaking. Apart from the management and administrative people, most major programs could warrant a full time quality manager, risk manager and schedule manager. You could have someone responsible either full time or part time to manage change. This could include changes within the PMO, but also possibly management of change within the company where introduction of the end result of your program may affect organization, structure, personnel and processes. In other words, they would manage what needs to be changed outside of the program to enable the expected and required result to be effective. You might also assign someone to manage program reporting.

Quality Manager’s Role
This is the person responsible for creating the program plan detailing quality, which could include:

  • Policy
  • Metrics
  • Assurance
  • Control
  • Audits
  • Internal and external standards to be met
  • Common tools and applications to be used – type and version/rev level
  • Method of updating of common tools and applications
  • Archiving policy

The quality manager would try to ensure consistency across all projects to give the program a common look and feel, and plan and manage regular quality reviews/audits throughout the life of the program to ensure the quality plan is being followed by each project. They would also ensure the defined metrics are being measured and reported as defined in the quality plan.

Risk Manager’s Role
This person would be responsible for working with individual PMs to identify and quantify risk on each project, highlighting those that need further effort to minimize risk at the project level, and assess any risks to other projects or the overall program by any one or more individual project risks. The risk manager would attend project level risk meetings and take the high level view on threats (or opportunities) at the program level, implementing risk reduction measures as appropriate. This person would be responsible for coordination between individual projects where appropriate.

Scheduling Manager’s Role
This person would work with individual PMs to ensure they had a schedule at the correct level of granularity, with critical path identified and processes in place for regular updating. They would then amalgamate these plans into a program level schedule at the appropriate level of granularity. This should then identify the critical path through the program showing which projects, or deliverables within a project, are on the program level critical path. This is key for the PMO to know, manage and review on a regular basis. The risk and scheduling managers would need to work very closely together, as any identified time risks can be monitored closely between them, particularly for deliverables/activities on the program level critical path.

Reporting
Reporting may not be a full time position in the PMO but it is a very important one. I was asked to create a reporting system for a major PMO and I designed a three-level reporting system. Each project completed a project level status report which was sent to the PMO on a weekly basis. These were rolled up and a PMO level report was created, automatically hyperlinking project information to a one line status report per project. Use of color was important (red, yellow, green) to identify problems where the PMO management might need to focus or work proactively to avoid or minimize impacts on the overall program.

The final layer of report was for senior management. This needed subjective judgments and assessment from the PMO so it could not be automated.

This role would also include financial reporting – actual costs to date, forecasts for future and comparison to the financial baseline/budget. This report would go to senior management so the specific information, format and frequency would need to be discussed and agreed with them.

Management of this major undertaking may depend on the size and complexity of the program but in my experience, a regular meeting of the PMO (including the individual PMs if possible) would review each project, scheduling and risk issues, changes and project issues, and resolve any conflict or interfaces between individual projects. Any potential threat to the overall program timeline, budget or deliverables can be highlighted, discussed, resolved and reported.

In conclusion, for very large projects (programs), the main PMO team could include the program manager, deputy, admin, scheduling manager, risk manager, quality manager, someone responsible for change, someone responsible for reporting and, in my opinion, each of the individual PMs. How many of these roles, and any additional roles such as external communications, security, networking, infrastructure etc., that may be required depend on the size, complexity and criticality of the program. Rather than assessing just the cost of the PMO which could be relatively high, it is more reasonable to consider the value the PMO provides compared with the cost of failure of the program due to inadequate management. Then a PMO can almost always be cost justified.

What positions have you involved in your large-scale project? What worked? What didn’t?


Control Your Project: Using the OODA Loop to Keep Your Projects in Control or Bring Troubled Projects Back on Track

Posted on April 22nd, 2013 in - Vicki Wrona, Best Practices, Budget, Lessons Learned, Management, Project Management, Reference Material, Reporting, Resources, Schedule, Scope | 6 Comments »

by Vicki Wrona, PMP

I recently learned about a tool called the OODA loop. While the tool itself was created based on military fighter pilot observations and is now often used to train law enforcement, it has applications for use in business and personal life as well. Here we will discuss the applications of the OODA loop in business, and more specifically, in managing projects.

First of all, OODA stands for:

1. Observe
2. Orient
3. Decide
4. Act

The concept of the OODA loop was first created by US Air Force Col. John Boyd during the Korean War. We all naturally follow this loop. If you are in a confrontation, you want to interrupt, or get inside, somebody else’s loop so that you instead of following, you now lead and can react faster than they can. At that point, they are chasing you on your OODA loop terms. This technique is often taught to police officers and law enforcement. For example, if someone were to break into your house, they know what they intend to do and so their OODA loop is ahead of yours. What you want to do is somehow disrupt their loop, or get inside it, so now you are the one in the lead. While this loop works well with quick reactions, it also works with longer-term decisions that need to be made. Let’s explore this.

In business, this can be used to manage projects, staff or operations. Let’s take the example of a project that is already in process. Once a plan is in place, the project manager will monitor the progress made on the project to make sure it’s on track. That is the first stage of OODA, Observe. The second stage, Orient, has to do with watching the work as it progresses, listening to what is going on, analyzing the reports that are pulled, talking to stakeholders, etc. In pulling information and data from as many sources and vantage points as practical, you can determine if the project is on track and progressing as planned. There will be variances from plan; you need to decide if they are normal or an indication of trouble. Based on this, you move to step three, which is to Decide what course of action, if any, is needed. Maybe you need to add more resources to a particular piece of work to keep it on time. Maybe you need to look at options to cut cost in order to stay on budget. That’s your decision here. The next step is to Act. You follow through on that decision, and then repeat the cycle to observe the impact of your decision and whether to take additional actions. By nature, this cycle repeats constantly throughout the project.

This technique can be very useful in noticing and rescuing a troubled project earlier rather than later. What we want to do is interrupt what is going on in the project and improve it.

This cyclical process may sound very familiar to experienced project managers. This is similar to the PDCA (plan-do-check-act) cycle made famous by W. Edwards Deming. The cyclical nature of these cycles is built into project management and should be done constantly to effectively and pro-actively manage our projects. The Six Sigma version of PDCA is called DMAIC (define, measure, analyze, improve, control). Kaizen, also called continuous improvement or “for the better”, also follows this concept. With kaizen, small improvements and corrections are constantly being made to keep a project on track or to improve existing processes.

The reason I like the OODA loop concept is because, at least for me, it adds an extra dimension to the PDCA cycle. This dimension is the thought of interrupting and getting inside the loop on the bad things that are happening on your project or within your teams. It enhances the ability to adapt more quickly by remembering that we have to interrupt the current flow of work or status quo in order to put things back on track. With our teams, we may have to shake up our team in some way to get them out of their current rhythm or comfort area in order to do what is best. It is also adaptive in that on projects, the plan you go back to when you have completed a cycle may be different from the plan before the cycle was completed. This is fine, as long as the proper change control processes and sign-offs are followed.

While the PDCA cycle is cyclical in nature, I have observed that it tends to be viewed more methodically, slowly and with a longer-term attitude. That is not always true, of course, but that is how it often comes across to me in practice. The PDCA cycle is not always long-term and the OODA loop is not always short-term and quick, but when thinking of these concepts, it helps for me personally to keep them both in mind in order to properly manage my teams and initiatives both quickly and methodically.

Here is a link to a good description of the OODA loop in business called The OODA Loop: Playing chess with half the pieces. It is a book review with notable quotes on agility, overcoming the numbers, planning and strategy, on not following the rules, and on culture as a long-term competitive advantage from the book Certain to Win.

Think about the OODA loop and how it may apply to your processes, operations, teams or projects. How can you use this new perspective to better manage those?


Retaining Employees: Be Nice, Get Paid

Posted on April 12th, 2013 in - Rob Zell, Best Practices, Communication, Leadership, Management, Resources | No Comments »

by Rob Zell

When teaching leadership and management skills I refer to maintaining and/or enhancing self-esteem as a foundational practice for all leaders. When I do, I typically get a few participants who give a very subtle eye-roll or smirk. I can understand why: as leaders in a fast-paced, bottom-line focused organization, who has time to manage the self-esteem of others? Aren’t we all big boys and girls? We all come to work and have a job to do, so let’s just set aside all the personal feelings and get the job done.

While it’s certainly true that we owe it to the organization to be a little thick-skinned about feedback and look at criticism as a means to improve, a little praise and recognition goes a long way. It also has a measureable impact on the organization and profitability. Don’t believe me? Let’s look at a couple of examples.

I recently found this post about a server who comped a dessert for a family because the kids were well-behaved in the restaurant. As a parent, I try to influence my kids to behave in restaurants out of respect for other patrons and the staff. To be recognized for your efforts as a parent by complete strangers makes you feel pretty good. The value of the recognition in this example was four dollars. But what’s the return?

  • Net profit* from family that returns to dine there one extra time (on a ticket of $60) = $3.00
  • Net profit from 10 extra guests from the family sharing the story (Average check of $20) = $10.00
  • Net profit from 10 extra guests who see the story on crowd sourcing review site  = $10.00
  • So the ROI is (($23 – $4)/$4) *100 = 475%   

*figures based on average net profit of 5% of guest check

Not too shabby. And I think my estimates are on the low end. A small amount of recognition, for something we hope all parents teach their kids (it’s what they are supposed to be doing – teaching manners, etc.), leads to a HUGE return on investment.

Of course most of the people I teach aren’t facing the guest. But they do manage or work with many people across the organization. How important is maintaining/enhancing self-esteem for those people? Let’s dig into that idea.

In a study by the Corporate Executive Board, discretionary effort is defined as,
“Employee willingness to go ‘above and beyond’ the call of duty, such as helping others with heavy workloads, volunteering for additional duties and looking for ways to perform the job more effectively.”

Discretionary effort and “Intent to Stay” make up employee engagement. Engaged employees are more committed both rationally and emotionally (read that as engaged heart and mind) than non-engaged employees. So how engaged do you think employees are? In the same study, researchers found that engagement rates had dropped by almost 4% in Q4 of 2012. The level of discretionary effort hovers in the 25-26% range for most industries.  The Intent to Stay metric hovers around 36%; the converse is that about 60% of the workforce is thinking about leaving their company in the next year.

So what’s the value of making an impact on these metrics? Let’s say we take an organization of 2,600 people. Using these figures, almost 2,000 are just “putting in their time” and about 60% (about 1,500 employees) are thinking about leaving, even going so far as to send resumes and make calls. Providing just a small amount of recognition, in order to engage 10% of the 2,000, could increase productivity and commitment. If just half of those were part of the 1,500 considering leaving, a mere 100 people, and they stay, we save approximately $1.1 million in turnover costs.

The point is that maintaining/enhancing self-esteem is easy, cheap and provides big return. It doesn’t take much time or effort to write a note, say “thank you” for quality effort or provide specific motivational feedback. Even providing developmental feedback with the attitude of “do no harm” can go a long way to engage and retain employees. We all like to feel that the work we do is valued and appreciated.

How often you provide recognition is up to you. The argument that we shouldn’t recognize people for doing their job doesn’t really hold up in the face of these figures. We hired people to perform a specific job for us. If we want them to continue to do those tasks with us and contribute discretionary effort, we owe it to them to provide recognition to keep them engaged.

What do you do to recognize your employees? Have you noticed a return on that effort?


Forward Momentum Logo
Forward Momentum Logo