Forward Momentum: Delivering Results

By Vicki Wrona, PMP

When it comes to projects, the classic definition of project success is to deliver a project on time, on budget and within scope. However, I’m not sure that definition is adequate. I think it’s time that we revisit the classic definition of success, at least with regard to projects.

If you’re like me, you’ve seen examples of projects which were delivered on time and on budget with the scope that was defined and requested only to find that the end result is never implemented or used. If the software that was developed during an application development project sits on the shelf and never gets used but otherwise satisfies the classic definition of success, we could say that we delivered a successful failure! After all, what good is the product if the end user never uses the technology or the application that we have developed?

Let’s take a look at the Millenium Stadium built in England. This particular stadium was built for a large event and was finished on time and on budget. Everybody hailed the project as a success when the stadium opened. It held that large event and then proceeded to sit empty and unused for a few years. (Note: the stadium is now used.) Is this project a success? For a while, it did not appear to be so.

On the other hand, we may be aware of examples of projects that have been delivered late and/or over budget but are now viewed as successful. One example would be the Sydney Opera House in Sydney, Australia. When the Sydney Opera House was unveiled, the project was seen as an embarrassment and a failure. The project took numerous delays, was way over budget and had some accidents resulting in deaths associated with it. But over time, this “unsuccessful” project has become the symbol of Sydney and a tremendous success. The opera house is impressive, used and loved.

Especially with regard to IT, we really need to revisit the definition of success. Delivering on time, on budget and within scope is not good enough. Too often we de-scope a project in order to deliver it “on time” and/or “on budget”, so it doesn’t often deliver all of the requirements that were requested. That is fine if everyone agrees to the change and to having a product with decreased scope, but it happens a lot. Also, we often don’t do a proper job preparing the end-user for this new product or service. Maybe we didn’t build a product that fully satisfied their needs after all. That’s a failure on our part. Maybe we didn’t provide appropriate and proper training. Maybe we didn’t give them time to get used to the new product or process or to get over their fears of a new system. Whatever the reason, it is hard to consider these projects a success if the application we developed is not actually being used correctly or at all.

What do you think? What would you propose to use as a new definition for project success? Let me know.

By Vicki Wrona, PMP

I was working with a group of people recently and one of them said, “It’s better to have 80% on time than 100% too late.” I love that statement.  Let’s explore that today.

A life lesson in college

When I was in college, I had an accounting professor who gave tests that were almost impossible to finish in the time allotted. His attitude was that he would rather see your work and thought process on all questions for partial credit than have a fully correct and complete answer on some questions. Those students who worked through a portion of all questions scored higher than those who completed some of the questions fully. In his view, it is better to provide 80% of most things than 100% of some things.

This is a lesson in life. We rarely have the luxury of finishing our to-do lists, or even the necessary and critical portion of our to-do lists. We certainly don’t get to those tasks designated for “when I have some free time”. It is a reality that we often must complete as much as we can as best we can in order to survive.

Relating this to our projects, our work and our lives

Isn’t it better for our customers to roll out a product or service that fits 80% of their wish list rather than roll out nothing (in an effort to be perfect) and serve 0% of the need? We have the option to improve the 80% to 100%, but often we leave that product at 80% either because of constraints or because it turns out that the 80% was good enough. Either way, it’s still better than 0%.

How many bright ideas are still just that – ideas? Isn’t it better to provide something rather than nothing?

I realize there are exceptions to this statement and that in some cases, like hospital or public safety, 80% won’t do. But even in those settings, there are places where improvements make a difference, even when they are not perfect.

A Caveat

Note: This doesn’t mean that sloppy or incomplete work is good enough. I realize there are people who consistently perform at levels not quite good enough. In their haste to do more, they are really performing at closer to 40%-60%, not the 80% I am referring to. Fifty percent delivery only creates more rework for them and for those they work with. That is not what I am talking about here at all.

What do you think? Is it better to provide 80% of most than 100% of some? How about 80% on time rather than 100% late?

By Vicki Wrona, PMP; Dr. Gerald Mulenburg, PMP

While talking with the team, we thought it would be fun to share some of the recent books that we have been reading and hear from you what you find interesting and relevant now. There is never a shortage of professional (and fun) books, so together, hopefully we’ll all find something new to read and enjoy!

Recent books from Vicki:

Books that I have recently completed and have enjoyed are as follows. Note: I listen to more books than I read, and not only are these good books, they are also well-narrated.

• On Second Thought: Outsmarting Your Mind’s Hardwired Habits by Wray Herbert – Interesting list of the shortcuts and biases that our brains use and how to become aware of them so we can enjoy the positive aspects and avoid the negative consequences of each. These biases include why 99.9% of the citizens of France but only 28% of Americans are organ donors, why people who are hungry for lunch donate less money to charity and why early birds serving jury duty are more likely to give in to racial stereotypes when the day gets late.

 

• If You Ask Me (And of Course You Won’t) by Betty White – this is a fun, light-hearted read. I listened to this in audiobook form and it was wonderful hearing Betty White read the book. Listening to her talk was like sitting down with a good friend and learning from her 7-decade career.

 

• The Steve Jobs’ Way: iLeadership For a New Generation by Jay Elliot, William L. Simon – read Vicki’s review of this book here. Listening to Jay Elliot, Sr. VP at Apple and one of Steve’s early employees, read this book and tell the story makes you feel like you were there.

Recent books and suggestions from Jerry:

Books that I have recently completed and have enjoyed are as follows. (This book’s theme parallels the book Vicki mentions, On Second Thought, which I can’t wait to read.)

• Thinking on Purpose for Project Managers: Outsmarting Evolution by Bill Richardson – If you’ve ever wondered why so many poor decisions are made on projects, this book identifies why, and what can be done about making better ones. In clear, no-nonsense writing, the author provides the background for why we make decisions the way we do, what is sometimes (often it turns out) wrong with the way we make them, and how to make better decisions through what he defines as thinking-on-purpose. A major problem in projects, Richardson says we’re often thinking on autopilot, which he defines as reacting to events as they occur using quick-and-dirty or good-enough solutions. He takes the reader through a series of simple steps to help recognize ineffective patterns of thinking, biases, emotions, and blind spots that cause these problems, and he describes how to improve awareness of them—how to think about what you think about.

 

• It’s Your Ship: Management Techniques From the Best Damn Ship in the Navy by Naval Captain Michael Abrashoff – read Jerry’s review of this book here.

What books have you recently read?

By Vicki Wrona, PMP

I recently read two articles by Roger Connors regarding how to increase accountability on our teams. (1-Accountability Leads To Greater Influence and 2-Uncontrollables?) While he is working with large organizations on complex projects, the principles offered apply to small teams as well. One of the complaints I hear from senior management is lack of proactive action by their employees or project teams. What I hear them talking about is accountability. In classes, I will often ask if participants have noticed that there are those managers or project managers who are able to get the better resources, more budget when needed, better management support and who tend to deliver more successfully? What do they do differently?

They act accountable for delivering results rather than sitting back and letting things happen to them. They are more proactive in a way that Connors offers as a simple thing to do. When working with a team, they often ask, “What else can I do?” This question posed to the team brings out new ideas, gets the team used to hearing the question and possibly thinking in these terms themselves. It is what allows teams to deliver more quickly by fixing inefficiencies or finding more creative solutions. It is what allows teams to deliver on budget when it seems that is not possible. It is what allows teams to discover new uses for either existing products or new products being created. It is what allows teams to educate the end user so the new process or the new product being developed is accepted, used or followed.

The other point made in these articles is that there is more in our control than most people initially believe. I often bring this point up when discussing risk with teams, and discussing steps that can be taken to prevent a threat or enhance an opportunity. We may not have final say in many matters (FDA approval, economic conditions, management priorities, etc.) but we can influence them to some extent, and often to a greater extent than we initially believe. Many people do not want to believe this, but again I will ask if you have seen someone who is able to influence more things than the average worker. Often, these people are not those high up in the org chart, but instead those who are proactive and willing to take accountability. To support this idea, Connors provides an example of a team who increased the speed of government approval tremendously, a process that many believe is out of their control.

What do you think? Do you believe we can influence accountability for ourselves and our teams? How have you done it?