Friday, March 19, 2010

Hope is Not a Strategy



I remember the first time I heard this phrase - a mentor of mine at Hewlett-Packard gave me this advice many years ago. He used that along with my other favorite "Denial is not a River in Egypt".

At the time, he was referring to an under-funded project with an unrealistic deadline. The team was tasked with building an Internet-based service offering (providing 24x7 access to Hewlett-Packard's support offerings) within a very aggressive timeline.

The biggest problem? It was the late 1990s. At the time, every division within HP's Worldwide Customer Service Organization wanted to "get in on the Internet". I had led the development and implementation of HP’s first Internet-based customer support system several years earlier (back in 1994). And we were planning a significant upgrade, leveraging online communities and other social networking concepts that would only become in vogue several years into the future.

But, what started off as a simple, focused project, quickly ballooned into a huge, multi-divisional effort. Because of this, the requirements kept on growing and growing. My team was encouraged to collect requirements from every group within every division. I facilitated numerous sessions - speaking with over 50 sales, marketing and product managers across 5 divisions.

It was daunting, yet exciting. It was during this time that I was introduced to my mentor, Emil, who worked in HP’s consulting services division. Emil counseled me on many topics – from business planning to software architecture. He taught me the 5 whys. He advised me on managing the professional services firm we were using to help augment our staff. He cautioned me on effective scope management.

Unfortunately, as the size of the project grew, so did the ambitions of my management team. Eventually, Emil told me that we had reached the point where we were trying to "boil the ocean".

Emil counseled me that the project was beginning to exhibit some of the classic mistakes outlined in Steve McConnell's book, Rapid Development: Taming Wild Software Schedules.

We needed to rein this in. We could not rely on “Hope” to deliver this overly ambitious project.

What did we do? Well, it wasn't easy. But eventually, we (my key partner and I) were able to convince our primary sponsor (a Division Manager) of the need to redefine success. That this was a multi-year project that needed to be deployed in phases. Our Division Manager was a seasoned executive who had been around the block. With Emil’s guidance, we were able to effectively explain the situation and alter our business strategy and service roadmap. Our division manager implicitly understood the issues and provided us the vehicle to move forward.

Eventually (and, on the original timescale), we introduced a simplified support offering that went on to become an award winning site for IT Professionals.

It’s interesting. I look fondly back on just about every project I have worked on over my career. Each had their own set of challenges and accomplishments. And, each had its own set of key learnings that I am able to take forward. This particular project has a special place, because of the opportunity I had to learn from my mentor. Thanks, Emil.



Post a Comment

0 comments: