Does Your Project Have an Elevator Statement? Did the Chevy Volt?

The Chevy Volt

Recently production was halted on the Chevy Volt due to low demand.  If you are not familiar with the Volt, it is a hybrid car that uses a battery powered electric motor, and has an additional gasoline motor that kicks in when the battery is exhausted.

The concept sounds good.  Everyone wants to be green and drive an electric car, but no one wants to run out of juice and be stranded from their home battery charger.  This anxiety has limited the purchase of pure battery powered vehicles where the typical driving range is 70 miles per charge.

Nissan Leaf

Chevy decided to address the problem by adding the option of switching to gas power if the batteries are drained, and you will never be stranded like you would be in a pure battery car, such as the Nissan Leaf.

When the Volt came out I questioned the level of feasibility work that was done, and how the business case was justified.  I saw the value of the Volt and I was amazed at the technology, but I also perceived many negatives that could limit the buying audience for the vehicle.

I believe that if the correct feasibility processes were performed Chevy may not have gone forward with the Volt.  For the purposes of this article, let’s do a feasibility simulation and see what could have happened at Chevy.

Starting Feasibility with an Elevator Statement
I train teams to start the feasibility process by creating an elevator statement for the project or product.  If you are not familiar with elevator statements, they concisely describe the justification for doing a project, or why this project makes sense to do.  Elevator statements do not discuss who, what, when, or where, but only focus on the business reasons for doing a project.

Elevator statements are brief and can be shared with a fellow elevator passenger in the short amount of time it takes to ride an elevator from one floor to another.  The thought is most people have a short attention span, and if you cannot summarize the value of a project in a concise paragraph, the project may not make sense to pursue.

The format of an elevator statement looks like this:

For (target customer)

Who (statement of the need or opportunity)

The (product or project name) is a (category)

That (statement of key benefit – that is, compelling reason to proceed)

Unlike (primary competitive alternative)

Our Product (statement of primary differentiation)

To demonstrate with an example, I imagine many years ago the Apple iPod may have had an elevator statement that looked like this:

For:     Music lovers

Who:   desire a simple way to listen to and manage their songs

The:    iPod

Is a:     portable digital music player

That:   provides intuitive, easy to use controls.

Unlike: other MP3 players

Our:    product provides seamless integration with a world class music store (iTunes)

So going back to the Volt, what could the elevator statement have looked like for this project?  Let’s assume that the Volt product owner, whom we will call “Jay”, created the following statement:

For:    Automobile drivers

Who:  desire a clean, efficient method of transportation

The:   Chevy Volt

Is a:    hybrid motor vehicle

That: is propelled by an electric motor and can go 35 miles on battery power

Unlike: the Nissan Leaf which is limited to 70 miles of range per charge

Our:   product has an onboard gas engine that can act as a generator for the electric motor and extend driving range by 340 miles

And

Unlike: The Tesla Roadster which costs $109,000

Our:   product only costs $32,000 after government rebates

Tesla Roadster

If a product owner creates an elevator statement on their own, I will have them vet the statement with a small subset of the project team.  This small team is often composed of a development lead, a test lead, a UX lead, and an architect. The small team will try to identify holes in the elevator statement and issues that the product owner overlooked.

Simulating an Elevator Statement Team Evaluation
Let’s pretend the following happened at Chevy when Jay reviewed the elevator statement with the small team:

Keith the architect points out missing infrastructure.  The Volt owner will need to install a charger in their home, at a cost of approximately $2000.  To get a charger the owner will need to go through an assessment of their garage, obtain a permit for charger installation, do the installation, then have the installation inspected and approved.  Not quite as easy as buying a gasoline car.

Laura the QA lead thinks that die-hard green technology enthusiasts will buy the Volt even if they have to install a charger.  However, Laura has concerns of her own.  Laura notices that the Volt may have a high Total Cost of Ownership (TCO).  Here is Laura’s hypothesis:

If a person buys a Chevy Volt they will spend $32,000 for the initial purchase plus $2000 for a charger. Each charging of the Volt will cost approximately $1.50 on the electricity bill.  The $1.50 of electricity is good for 35 miles of range.  Continuing with this cost of ownership hypothesis, Laura says the average person drives 15,000 per year, and they keep a car for 5 years before selling and trading it.

Summing all of the items above, Laura determines that the total cost of owning a Volt for 5 years would be:

$32,000(car) + $2,000 (charger) + ($642 (electricity cost per year) x 5 years) = $37,210 

To give this perspective, Laura asks Jay to compare the Volt to a gasoline car that Chevy sells, the Chevy Cruze eco. The Chevy Cruze has a price of $16,800.  If the average person drives 15,000 miles per year, and gas costs as much as $5 per gallon, the total cost of owning a Cruze for 5 years will be:

$16,800 (car) + ($1785 (gas cost per year) x 5 years) = $25,728 

Laura concludes her point by saying a person could get a nice car plus a nice motorcycle (a new Suzuki GS 1000) for the cost of a Volt.

Chevy Cruze

Scott the developer does not want to pile on to the negatives, but he has his own point for Jay.  How long are the batteries good for?  Jay says the batteries are warrantied for 8 years, and right now he guesses a replacement battery pack will cost $3,500 in the year 2020.

Summarizing the Value of Elevator Statements
Let’s leave the simulation and reflect on the main goals of an elevator statement.  Here are 5 reasons I use elevator statements with my project teams:

  1. If you cannot concisely describe why you are doing a project, you have an immediate red flag.
  2. An elevator statement is a great tool to be reviewed by a small group for feasibility.
  3. An elevator statement review with a project team is a great way to get project buy-in.  Most teams are just told to build something.  Teams are not usually asked if they would approve of a project.  Involving the team in feasibility helps build passion and support for a project.
  4. An elevator statement review is cheap and can help you decide to cancel a project before going into an expensive and detailed ROI analysis.
  5. Elevator statements help the team design the product.  By knowing why we are doing a project, we can tailor the design and tradeoffs for the main business goal.

In summary, I am a huge fan of the elevator statement and use them with all of my clients and projects.

*Important disclaimer.  The author owns a Chevrolet product and was in favor of government support to keep GM going during the recession.  This blog post questions the process used to justify the Volt, but makes no comment on GM as a company or the Volt as a product.
Advertisements
Posted in Agile Practices, Uncategorized | Leave a comment

The Problem with Red, Yellow, Green Project Status

Many years ago I worked in a Project Management Office at a large financial institution. Once a week I prepared a project status report for executive management and the PMO director. I would calculate how we were tracking to budget, list any major issues or risks, and summarize overall status.

I was also told to mark the project as red, yellow, or green – using the following definitions:
Red: Serious issues and the project will probably be delayed or have significant budget overrun.
Yellow: Potential issues with schedule or budget, but both can probably be saved with corrective actions.
Green: On schedule, on budget, all good.

The red/yellow/green approach seems simple and logical. You only worry stakeholders if something goes wrong, so green projects do not need much review or attention.

However, in my experience the color approach has many shortcomings and potential repercussions. Let’s look at few.

Expectations
What happens when a green project turns yellow or red? In my experience there is an emotional conversation with stakeholders. Here are some of comments I frequently hear when a project goes from green to yellow:

“What went wrong?”, “Why didn’t you manage this project better?, “How can we avoid this happening again?”, “Why didn’t you see this coming?”.

As a project manager I often feel great guilt with these conversations and I too question my competency. But if we spend a moment and work our way through the guilt and emotion, we can see this issue from a more analytical perspective.

Not in line with normal project uncertainty
You may be familiar with the cone of uncertainty. The cone of uncertainty tells us that you cannot completely understand all of the tasks and potential issues within a project, at the beginning of a project. As the project progresses we learn more and there are less risks, but we can never anticipate everything that could go wrong until the project is 100% complete.
When we label a project as green we are telling the sponsor everything is OK, today.
Sponsors interpret green as everything is OK today and it should be for the entire project. It is human nature to assume the project is under control and should stay under control.

A Different Approach
But since any experienced project manager knows that green does not necessarily mean green forever, we need to speak in verbiage that stakeholders can relate to. To address this issue I have changed my color scheme when working with sponsors and removed green from my status options.

My options are now:
Yellow: The project does not have any known issues but there is still high risk that something could go wrong (as demonstrated by the cone of uncertainty). As with any project in flight, we are managing it cautiously and we are doing our best to deliver successfully.
Orange: An issue has surfaced and the project goals are in jeopardy. We are triaging the issue(s) and at this time we believe we can still be successful
Red: An issue has surfaced and we do not believe 100% project success can be obtained due to the discovery. More than likely we will either miss the desired date, or exceed budget, or not be able to deliver the desired scope by the target date.

Conclusion
What do you think of my approach? I welcome your thoughts. I know many stakeholders will “freak-out” at seeing no greens, but I believe all projects are yellow until they are delivered.  We need to teach stakeholders that this a reality of doing business.

Posted in Uncategorized | 24 Comments

Work In Progress Limits at Subway?

A few days ago I was in a daze as I waited in the line at Subway.  I was thinking about a dilemma my friend Phil had.  Phil is a project manager for a team that creates internet applications and web pages for a large company.

Phil wanted his team to start working on larger projects and provide more value than delivering simple enhancements to the existing websites.  The problem was his customers never stopped asking for new modifications or slight changes to the pages and mini-apps his team had already delivered.  In Phil’s estimate there were approximately 50 enhancement requests in his team’s work queue.

Every time the team received a new request they discussed it with the customer, then estimated when they would deliver the request.  In essence they were constantly taking on more work, and the more they discussed the new requests, the less time they spent delivering the ones they had already started.  In the words of Lean Software Development, Phil’s team needed to “stop starting and start finishing” the requests that were already in progress.

I told Phil this in essence and emailed some screenshots to him of the Kanban boards that many teams use to limit the work in progress.  Phil was still having a hard time grasping the concept after I discussed the screenshots with him on the phone.

…..…then I snapped out of my daze as the Subway line shortened and I found myself face to face with one of the sandwich makers.  “What can I get for you today?” Sally the sandwich maker asked me with a smile.  I placed my order for the Philly Cheesesteak then stood back to watch the same process I have seen at Subway for many years.  Sally said “would you like it toasted?”  I said yes.

Sally took my bread, placed it in the toaster, then looked down the sandwich line to see what was going on.  Two co-workers were diligently adding veggies and sauces to two sandwiches already in progress.  In a few seconds they would be done.  Sally took off her gloves and moved to the cash register, arriving in time to wrap the sandwiches and charge the two customers.  As this happened one of Sally’s coworkers moved to the start of the work queue and asked the gentleman beside me what he would like.  As this happened the other co-worker pulled my bread from the toaster and asked me what veggies and sauces I would like.

I always take the Subway sandwich process for granted, thinking to myself “they are just making sandwiches, it’s no big deal”.  But sitting here and thinking about Phil’s problem, this simple sandwich process was exactly the model he needed to visualize.  The Subway crew was versatile and agile, but they never over committed and never took on more orders than they could complete at one time.  In essence they had set limits on their work in progress.

I am sure you have witnessed this yourself.  The Subway location I frequent is very small and sometimes the line goes out the door, frequently with folks standing in the rain.  I never see this change the process at the sandwich station.  The crew still only takes on as many orders as they can focus on and deliver effectively.

I spoke to Phil after my lunch ritual and the Subway analogy connected with him.  Today his team limits the work in progress, and they have “stopped starting and starting finishing” more enhancement requests than ever before.  They now have capacity to go beyond maintenance and pursue new projects that can provide high value to his company.

Posted in Agile Practices | Leave a comment

The Story of the Good King and the Bad King

James was the prince of Pragyle when his father became ill and passed the throne to James.  James had watched his father for years and knew what he would do when he became king.  James set out to make life better for the citizens of Pragyle.

James looked at the local roads.  He identified two bridges that were close to breaking and he instructed his carpenters to reinforce the bridges.  The citizens had no idea James’ maintenance work prevented a future disaster.

James looked at the budget for the coming year.  He could see that taxes would need to be raised to provide all of the services the kingdom had budgeted.  Instead of raising taxes, however, James met with the financial advisors of the kingdom.   They identified many projects that really weren’t that important, such as creating a painting of James on the side of the palace, or performing a research study on the quality of moat water. By cutting out the waste James avoided raising taxes, and the people of the kingdom never realized they had been saved from additional expense.

James monitored the kingdom next door, Wötterfal, on a daily basis.  He managed the risk of an impending war by watching every movement the Wötterfal troops made, and he warned them any time they approached the border of Pragyle.

Throughout James’ tenure, the people of Pragyle were solicited for their rating of James.  James always scored “good” on a scale of poor, fair, good, and great.

Unfortunately James died in his sleep after 10 years as the king of Pragyle.  James did not have any offspring and was replaced via election.  The people of Pragyle elected Eli the Plumber to replace James.

Eli took over and enjoyed all of the luxuries of being king.  He ordered lavish dinners, had his face painted on the side of the palace, and spent most of his time playing backgammon.  Eli thought to himself “Oh my, what an easy life James had.”

As time passed, Eli learned that running the kingdom was not all fun and games.  Soon one of the old bridges of the kingdom collapsed and 40 citizens plunged to their death.  Eli made a proclamation that the bridge would be rebuilt with better materials, and this would never happen again in the kingdom.  The citizens cheered Eli’s visionary thinking.

Next, Eli had a budget issue.  The new mural on the side of the palace was expensive and so were the lush parties.  Eli would have to reduce costs elsewhere in the kingdom, or increase taxes on the citizens.  Not wanting to be unpopular, Eli reduced the amount of monitoring that was occurring with the neighboring Kingdom of Wötterfal.  Instead of having surveillance soldiers watch Wötterfal every day, he reduced surveillance to once a month.  The citizens would still be happy because their taxes did not increase.

Unfortunately soldiers from Wötterfal crossed the border of Pragyle between the surveillance periods.  A farmer of Pragyle spotted the advancing troops and ran to the castle to warn Eli.

Eli quickly called the soldiers together and screamed for the soldiers to hastily gather their weapons and fight for the survival of Pragyle.  The soldiers were at a disadvantage since the Wötterfal soldiers were armed and ready to pounce.  After two weeks of fighting, and 900 soldier deaths, the Wötterfal army was repelled and Pragyle was saved.  The citizens chanted Eli’s name.  His stimulating speech had inspired the Pragyle army to save the day.  When the citizens were surveyed later that year, they gave Eli the ranking of “great” and they all mused how James had never suggested building a bridge with better materials, or how he had never helped rescue them from the Wötterfal army.

How does this relate to software projects?  How often do you reward the developer who saves the day at the end of a project, when they end up fixing a bug of their own making? How often do you reward the developer who kept their work on track throughout the project, and did not need a fire drill at the end of the release?

We all like heroes like Captain “Sully” Sullenberger, who lands a flight on the Hudson after running into a flock of birds. But how much recognition would a ground controller have received if they had directed Sully’s plane to a different location and avoided the disaster all together?

Be successful on your agile projects.  Recognize the people who prevent disasters, not just those who save you from them.

Posted in Agile Adoption | 1 Comment

Selling a Tradeoff Matrix to Your Customer

ImageFor many years I have been training project managers to create a Tradeoff Matrix at the start of a project.  The matrix is a great tool for reaching common agreement across all stakeholders on the areas to be emphasized during a project.
Unfortunately I should know better than to start a conversation with any business partners with the words “tradeoff”.  From a PMs perspective it makes sense to say tradeoff.  From a customer  perspective tradeoff means “I don’t get what I want”.
To avoid this potential conflict we can speak to the customer in their own terminology, and with an emphasis on how the matrix helps them versus saying there will be limits on what they receive.
I have started telling the customer this is a Focus matrix.  I tell the customer, “Our goal is to deliver on time, within budget, with the scope you desire……but, if the project becomes compromised for any reason, what is your highest priority?”
The matrix helps the team think about your most important project attribute every day of the project, so they do not miss your most important area.  Do you want us to focus on the date?  Then we will make sure we code to the minimum spec. and work with you to make sure we only develop the minimal viable functionality.  Do you want us to deliver all of the scope you asked for from day 1?  Then we will bring in additional help and spend the time it takes to deliver your entire scope.
I think you get the point.  We can discuss a tradeoff matrix with stakeholders with a focus on benefits to them, versus the tradeoffs they may have to make to ensure project success.
Posted in Uncategorized | Leave a comment