More, Better, Faster January 19, 2008Posted by Chuck Musciano in Leadership.
Tags: Project Management
Perception is everything. My mentor on the operations side of this business, Bill Rauscher, long ago drilled into me that the customer’s perception is my reality. It doesn’t matter what I know to be true; what the customer thinks is true will rule the day. My job, in delivering good customer service, is to get the customer’s perception to more closely align with my understanding of the truth.
This was driven home to me, once again, as I considered ways to decrease the time it takes to complete projects and deliver new tools and capabilities to my customers at work. These are internal customers; we provide tools and systems that let them do their jobs and serve our external customers better.
From the project team perspective, we make constant progress on our projects. Concepts evolve into requirements, which drive design, which fuels development, which enables testing, which leads to deployment, which lets us declare victory and move on to the next project.
Our customer’s perspective is very different. As we work our way through the phases of a project, their perceived value is nothing, nothing, nothing, nothing, and nothing, followed by everything when we finally deploy. They get frustrated as time goes by with nothing delivered. If you graph the two perception curves, it looks like this:
How do we fix this? Traditionally, we try to accelerate the project schedule, driving the time to complete the project down and pulling in the magical deployment date. Getting things done sooner is good, but all you’ve done is shorten the “got nothing” time that is frustrating the customer. Moreover, there is a limit to tightening the project schedule. At some point, you’ll be making the traditional choice between time, money, quality, or your job.
I think a better approach is to find ways to release incremental value to some customers earlier in the development cycle. You can’t everything to everyone, but you can give some things to some people. For that subset of customers, they are getting value earlier, and their perception of your ability to deliver goes up. The curve becomes this:
Some would argue that the small increase in early value (the area under the curve before the final deployment) is not large enough to make a difference. I contend that any additional value is better than none, and for the users who get that early value, their perception is that they are receiving close to 100% value that much earlier.
There are a few ways you can accomplish this. You might develop in phases and release partial functionality as it becomes available (some value goes to everyone). You could engage a willing pilot group to use early versions of the product, giving them value and getting great feedback in the process (all the value goes to some people). You will most likely find some variation of these extremes, opening up some value to some people as it becomes available and they are capable of accepting it.
As always, this must be done prudently. You can’t release poor quality stuff early, and some projects do not naturally lend themselves to an incremental release. Still, if you evaluate this approach for each of your projects, you’ll find ways to get some value out there earlier, which is more than you are delivering now.