Voices on Project Management

by , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with - or even disagree with - leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Cecilia Wong
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy

Recent Posts

Level 5 Leadership: Taking Your Project from Good to Great

Sprinting a Marathon

How Managers Can Grow Into Leaders

Managing The Last 100 Feet

The Network Diagram Mentality

Managing The Last 100 Feet

My father spent decades working for a telephone company. When I was quite young, he took me to see a large centralized telephone switching facility. I was amazed and enthralled at seeing all the technology it took to carry a person’s voice over a telephone line between houses on a street or across oceans. Leaving the facility, he told me, “You know, all of what you saw here doesn’t matter unless we can get the last 100 feet of a person’s phone line right.” Although the end-user experience back then consisted of selecting numbers on a rotary dial, there were still many technological considerations in getting things to work in the last 100 feet from a telephone pole to a house. 

 

Over the span of my project management career, I’ve realized the wisdom in getting those “last 100 feet” right for an end user — and how doing so is an essential part of the success of a project. Here are important components for getting those last details right:

 

1. Find end-user stakeholders. It is very common to have one or more stakeholders who are leaders in an organization. Stakeholders who are leaders provide essential strategic direction to a project. However, it is equally important to get the perspective of the people who will eventually use the outputs of a project. In addition to leadership stakeholders, create a group of end-user stakeholders that can provide a detailed perspective on these outputs. This balance of stakeholders between leadership and end users will give an all-encompassing view to help the project meet objectives.

 

2. Mind location. Quite often, a project manager is physically located near the project’s leadership stakeholders. However, certain types of projects that involve the creation of new processes and products would be better served if the project manager were located closer to the team serving end users, or the end users themselves. Doing so provides additional visibility to factors affecting the project that may come up in formal meetings. For example, the president of a global automobile company prefers to be located out on the design floor so he can have clearer communications with his designers, which results in higher-quality automobiles.

 

3. Develop functional success criteria. Much of our project management time and efforts focus on meeting functional requirements. But it’s also valuable to know how well we are meeting these requirements. To improve the quality of the outputs of a project, document functional success criteria for each requirement. For example, if a requirement states that a process is intended to produce a certain product, also specify performance criteria for the product. This can include functional success criteria such as: “Billing information must be displayed within two seconds for a customer inquiry 99 percent of the time.” Adding functional success criteria will promote end-user satisfaction and overall project quality.

 

4. Measure outcome-based metrics. We all know the value of measuring our project performance with A Guide to the Project Management Body of Knowledge (PMBOK® Guide)metrics such as schedule performance index (SPI) and other useful progress indicators. While these measurements are important, we also need metrics that measure the performance of the outcomes of the project. These can include adoption rates of a new process, evaluating end-user satisfaction with a survey and analysis of labor costs to complete a task. As these measurements typically occur near the close of the project, they can be conducted by someone other than the project manager.

 

It has been many years since my father took me into the telephone switching room. However, his comments about the importance of getting it right to the very end have stayed with me throughout my own decades-long career.

 

Do you have any tips on managing the “last 100 feet”?

Posted by Kevin Korterud on: December 05, 2014 10:33 AM | Permalink | Comments (4)

The Network Diagram Mentality

You want your projects to get off to a good start and end without major glitches. However, what typically happens is that projects begin with many unknowns and continue to progress with more unknowns. Not only that, projects hit many bumps along the way — and you are constantly addressing problems, attempting to resolve issues and rallying to minimize risks. 

Faced with this, I recommend approaching projects with a “project network diagram” mentality. (A network diagram is a planning tool that shows sequences of tasks, dependencies on tasks and impacts on a project.) Here are tips on using a network diagram mentality for managing project schedules:

1.   Count backward. There are tasks that inevitably depend on each other and have specific time frames. For example, it might take 10 days for one task to be done and 15 days for dependent tasks to be complete. So right away, you know you already need 25 days for that project. So these start-to-finish and other connecting relationships matter when building a schedule, as do float, slack and critical path times. These are all time factors you consider when doing backward counting. The technique of counting backward helps define the schedule because you focus better so as not to miss a number or a task. 

2.   Look in other directions.  A horse can see in one direction with one eye and in the other direction with the other eye. A project manager needs to do the same and constantly be aware of the surroundings. A network diagram offers this peripheral vision by encompassing all the aspects that matter to the project — and helps you set boundaries. A view in one direction can focus on what’s happening in the project. The other direction could be the bigger picture of your project. Let the boundary be what could potentially surface from either of those directions. For example, say your company has a portfolio of projects it has to complete. So at the same time you’re keeping an eye on the spending on your project, you also want to be aware of whether the company will be able to maintain your resources over the length of the project, especially in an economy in which layoffs happen all the time. If your company has to release some of your resources, what then would be your contingency plan to still make sure your project can be completed?

3.   Keep the end in mind.  Have an idea of the goal the project should achieve. Encourage team members to maintain a layout of their tasks in a way that identifies and prioritizes what must be done and can be done to reach that goal. Then, inspire your team to approach all tasks with confidence. In a network diagram, after having laid possible connections together, the project manager sets controls in place, giving him or her the capability for more optimal opportunities of project success. Manage your time and your project team’s time based on making it to the finish line.

What method do you use to help you prepare for and better manage project schedules?

Posted by Bernadine Douglas on: December 02, 2014 05:41 PM | Permalink | Comments (2)

6 Obvious Budget Overruns to Avoid

Categories: Project Planning

Voices_Marian_Cost Overruns_v2.png

Nowadays, we rarely hear about projects that finish below a given budget. On the contrary, we hear about projects that need more people, more material resources and more time, which ultimately translates into additional costs that strain the project budget.

Although it is clear that project costs can be influenced by external factors beyond the project manager's control, there are at least as many factors that can be controlled from within the project, through appropriate project cost planning.

Here are six simple reasons that projects incur cost overruns -- and how to prevent them:

1. Underfinancing. You've probably heard about projects that start with an undersized budget ("We could only allocate that much for this project..."). Such projects will have a high risk of overrunning the initial budget, as well as a high risk of failure. 

Mitigation: Clarify with the project sponsor from the very beginning how cost overruns, which are very likely to occur, will be handled -- for example, through scope reduction or additional funding.

2. Unrealistic costs estimates. Projects that have costs estimated based on gut feelings or inexperienced personnel are poised to face budget overruns. Biased and inaccurate cost estimates are likely to look unrealistic at a later stage in the project.

Mitigation: Break down the work into smaller and more assessable packages. Get help from subject matter experts and experienced personnel when estimating costs. Make the cost estimations comprehensible, by applying different estimation techniques (e.g., three-point estimates, parametric estimating or bottom-up). 

3. Underestimated complexity. Many projects nowadays, especially larger ones, have constantly growing complexity. The Berlin Brandenburg Airport and Terminal 1 of Munich Airport, for example, were quite similar in scope, but conducted at different times (25 years apart). Yet Berlin Airport, the more recent project, continues to have considerable budget overruns and delays. One of the reasons: the underestimated complexity concerning the financing of the project, the construction of futuristically designed facilities and newer regulations.

Mitigation: Split the project in smaller work packages or phases. Avoid planning everything extensively from the very beginning (the planning alone of the Berlin airport project took 15 years). Plan iteratively -- per work package or phase -- and throughout the project.

4. Extended project schedule. Just because the project schedule is met doesn't necessarily mean the budget will be met as well. On the other hand, it is highly likely that if the project schedule is not met (for example, due to a project time extension), then the project budget will be blown thanks to additional costs that may pile up, since the project team and resources will be needed for longer. 

Mitigation: Manage the project time and schedule well. Focus especially on the tasks on the critical path, which can have the most impact on both project schedule and costs. If you get asked to extend the project time, explain to your stakeholders that this probably will cost more. Remember the scope-time-budget project triangle. Time is money!

5. Improper buffer planning. If you don't plan (or plan improperly) for a budget buffer, the smallest deviation in scope or schedule will cause an overrun. 

Mitigation: A budget comprises estimated cost and some contingency. Plan the contingency for unexpected scope changes, unusual weather changes or possible problems with suppliers. Consider a buffer for the costs that cannot be accurately or predictably estimated. Some of the cost estimates will be more accurate than others -- for example, commodity prices will be more predictable than labor costs for a specific service.

6. Improper resource planning. Labor resource costs could be one of the project's biggest expenses. If the project lacks labor resources, a later labor force acquisition will be an unexpected project cost. It can also mean a higher cost since the contracting conditions might not be the same as when initially planning the project. Similarly, resources allocated in excess will mean unnecessary allocated costs, plus unnecessary blocked resources that could have been useful on other projects.  

Mitigation: First plan the scope, then the required work to be done, and then the related assumptions, dependencies and risks. This will facilitate a better understanding of the work needed to be done and hence will help better assess the right equipment, amount of resources and required skill sets.

How do you manage costs on your projects, and which measures do you apply to avoid cost overruns?

Posted by Marian Haus on: August 04, 2014 09:59 AM | Permalink | Comments (0)

Great Time Management Is in the Details

Categories: Project Planning

Voices_Bernadine_Time v2.png

Bringing together all the aspects of a project -- including stakeholders, team members, software tools and project requirements -- is just the beginning. Once we gather all the pieces of the project, we cannot sit back and relax. Properly controlling a project hinges on using time management skills to see it through to the end. And those skills consist of these three types of actions:

Reactive. There will always be an aspect of the project that needs to be tended to: risks and issues that may need near turnaround resolutions or disparate interests of team members and stakeholders that need addressing. But it's how we've set the stage for our project that will help us steer the project to the finish line, so allot some time to plan for issues to come up. Always be aware of how your surroundings and other resources may affect your project and how they can be of value at another point. For example, when your project is heading into a critical situation and you have no resources that can help, have a contact at the ready who may be able to get an immediate resolution.

Co-active. This element entails taking collective action toward correcting an off-schedule project. While we set out to have a process for every action, somewhere along the line, the schedule starts slipping or team members aren't reporting bottlenecks or bad news in a timely fashion. In these instances, reset the tone of your project control. My technique is to keep the scope constantly visible, usually by making sure the agenda has it displayed. However, I didn't do this on a project years ago. The developers were making ongoing enhancements to the software, ones that would be very useful at a future point. Yet they were very off-scope. The co-active measure was to pull back on the enhancements and redefine the scope to get it to what the sponsor originally requested. I did so by meeting with the sponsor and development team manager and reviewing requirements from the standpoint of: 

  • Which elements are most important
  • What doesn't have to be implemented immediately
  • What has been designed that can be kept 
  • What can be released in a quick turnaround
Proactive. But what if a project has components that are not fully defined yet? This is a situation in which we're not reacting to the existing project or controlling project issues, but instead considering the future: possible risks, another project's potential impact or information a stakeholder may want. Here I would recommend actively anticipating what may be helpful that has not yet been discussed. And this consideration can be addressed perhaps as an earned value chart, a report outlining project enhancements for future work or something as simple as organizing a meeting with sponsors to ensure there are no new impacts on the rise.

Are there any aspects to managing your time in a project that you see as helping to bring the project to a smooth close?

Posted by Bernadine Douglas on: June 06, 2014 05:00 PM | Permalink | Comments (1)

What Race Cars Can Teach Us About Projects

Categories: Project Planning

My last post on when to pull over a project to the side of the road generated much action on the Voices on Project Management Twitter feed. Here, I'll expand on that theme by highlighting the similarities in the makings of a race car and a successful project.

Today's race cars are a marvel of engineering and performance. They achieve these results while being extremely complicated and operating in harsh environments. However, to the spectator, racing appears to happen easily and naturally. When we see a race car whiz by, we don't see the many hours of planning that go into achieving both high speed and durability. 

Therein lies the parallel between race cars and projects. As project practitioners, we need to consistently ask ourselves whether our "project race car" is ready and able to win the race. This includes design and preparations before the race as well as vigilant monitoring of performance. 
 
Here are four essential components of a "project race car" that have to be well engineered and constantly monitored for your project to be a success: 

  1. Engine: At the heart of any race car is its engine. The engine provides the power to move the car down the road to the finish line. Great effort goes into the design, operation and monitoring of the engine to extract the maximum horsepower. The engine is similar to the project's business case. It also serves as the "horsepower" to drive the project to its desired outcome. If your project business case experiences events such as new or changed assumptions that cause it to lose momentum, then your project will start to fall behind and potentially stop. As with an engine, good business case design and constant attention to its performance is essential to project success. 
  2. Chassis: The power from the engine of a race car is transferred to its chassis, or structural framework, to propel it safely down the racetrack. The enabling infrastructure of the frame, wheels, suspension, steering and aerodynamic body all contribute to a smooth, fast ride. The same can be said of the methods, processes and tools that are a critical part of any project. These project management essentials must all be employed to work together in harmony for the project to move down the road. Could one imagine starting a race without all of the wheels on the car? Unfortunately, many projects do so without having the right fundamental elements in place. 
  3. Fuel: On a race car, the amount, type and consumption of fuel is a key factor in its ability to win a race. Each year the governing bodies of racing organizations work to tighten regulations around fuel to both achieve higher engineering performance and reduce environmental impact. Failure to select the proper type and amount of fuel can prevent a car from making it across the finish line. Many times I have seen project reports in which the overall status looks favorable but there are unstaffed roles. This lack of resource "fuel" can also prevent a project from getting to the finish line.    
  4. Driver: Even with the most advanced race car, it takes someone to help start it and confidently move it forward at the fastest but safest speed. In addition, the driver must also constantly monitor engine, chassis and fuel state as well as external conditions that will affect the pace of the race car. For projects, the driver is the project manager. The project manager must effectively start and guide the project, while also monitoring and adapting to external conditions such as other project dependencies and risks. 
How many times have you started a project "race" though one of the previously mentioned components was missing? What is the most frequently omitted element in the "project race car"?

For an insider look at car racing, read about a recent keynote speech on Formula One by Mark Gallagher at PMI® Global Congress 2014 -- EMEA.
Posted by Kevin Korterud on: May 23, 2014 10:38 AM | Permalink | Comments (3)
ADVERTISEMENTS

Disbelief in magic can force a poor soul into believing in government and business.

- Tom Robbins

ADVERTISEMENT

Sponsors