|
 Project Management Professional with 20 Years Experience
I’ve been initiating and managing projects since the age of 18 when I worked at Stanford University in the Center for Information Technology: I wrote project plans for - and supervised the installation of - data networks for campus departments that wanted to connect to the university’s IBM mainframe computer. My father and I then co-founded a successful Bay Area company doing the same work for the private and government sectors. I wrote proposals, developed project plans, and managed the installation of complex computer networks for an additional 13 years before deciding it was time to move on. That’s when I began a career in technology sales, focused, naturally enough, on computer networking equipment and services. It wasn’t long, though, before I found myself once again managing technology projects.
The Great Equalizer: How Project Management Saved a Company
The following anecdote illustrates the powerful role that project management can play in the success of a company. It’s a story about a company that was close to failure (its product set wasn’t generating enough revenue to keep the company afloat), and what was done to save the company from certain disaster. In the story, I suggest that in this company’s darkest hour, it was the management team’s decision to embrace formal product management practices (and, by inclusion, project management practices) that saved it from ruin.
I tell this story knowing full well that others who were there would hypothesize differently, claiming it was some other set of factors altogether that saved the company. This conundrum reminds me of the legend of The Six Blind Men and the Elephant: Each of the blind men touched the very same elephant in different places, and thus described it in quite different ways. Likewise, the story that each employee would tell about the cause of this company’s near ruin would depend largely on which factors they were blind to. Of course, in reality there was far more to the ultimate success of this company than simply adopting a set of business practices that I happened to think were valuable. But those adopted practices did play a part; an important part, I say a large part. Read the story and decide for yourself.
A Company Amok
I worked in outside sales for about three years before the company I worked for was forced to nearly halve its head-count and change its direction and business practices or face bankruptcy. Executive management was slow to react to competitive pressures that were causing its flagship product to slowly lose ground, and the engineering staff operated with a degree of autonomy that allowed them to ignore marketing’s pleas to make important product changes that customers wanted. Engineering believed their solution was more elegant than, and technically superior to, our competitors’ solutions, and this was very much an engineering-centric company that viewed marketing - especially sales - as a necessary evil to be tolerated, placated, and (for the most part) ignored. When I’d witness conversations between the VP of Marketing and the Director of Engineering, I could sometimes almost hear the engineer’s thoughts: “This is an engineering company and we don’t need a bunch of glad-handing sales types telling us how to design great products! It’s not selling because you don’t know how to sell it!” It didn’t help that the CEO was a very bright Ph.D. mathematician / engineer who loved nothing more than to engage in deeply thoughtful conversations with his fellow engineers, whom he held in the highest esteem. Even he saw marketing as something that had to be done rather than something that was just as important as inventing new technologies and solving technical problems.
With product sales too low to pay the bills, the company was running out of cash. The executive staff had to concede the market for our core product to our competitors, who paid a lot more attention to what customers wanted than we did. We got it wrong, and we didn’t have enough capital to recover from that. For the company to succeed, we needed a new product to sell, a killer app to save the business, and we needed it immediately.
Hope Emerges
The technology that would make it technically plausible for phone companies to deliver high-speed Internet access to households via existing telephone wiring (DSL) was just emerging. As luck would have it, our company owned a small, but very important, piece of code that, with a little tweaking, could solve a technical problem that was hindering DSL deployment worldwide. Simplifying: For a home computer to talk over the Internet, it must first have a short conversation across the wire to get permission to talk, and to learn the Internet address it will use for the duration of its Internet session. The software for this short conversation already existed for dial-up connections and was included in Microsoft and Apple operating systems, but PPP wouldn’t work in its native form over DSL.
Phone companies around the world needed an immediate solution for this problem, and the first company that could get this piece of software right stood the chance of making a lot of money very fast and being acquired by one of the emerging players in the DSL hardware business. We had the software that could be the foundation for a solution to the phone companies’ problem, and we knew it could be our salvation if we could avoid the mistakes we had made in the past. But developing PPPoE didn’t take a rocket scientist, and other companies had their eye on this prize too. We all knew that eventually PPPoE would be included as a minor component in Microsoft and Apple operating systems, but until then, phone companies would pay handsomely for an interim solution.
Overcoming our Past
Before we could move forward with PPPoE, we had to overcome the friction between marketing and engineering over the cause of our collective failure to succeed with earlier products. Marketing saw engineering as arrogant and inflexible, building admittedly elegant products, but products that customers didn’t want. Engineering saw marketing as a barely necessary evil; a bunch of whiners who blamed their inability to sell a perfectly good product on the engineers who designed it.
Like this elephant of Indian legend, failure and success can often be
described in many different ways. Objectivity is a project manager’s strong ally.
The executive team knew that our success with PPPoE demanded that they create a genuine partnership between engineering and marketing, difficult as that might be. For the first time since this engineering-centric company was founded, they chose to assign a person to manage all aspects of a product’s development; to learn and articulate the needs of the market, and to make sure that engineering clearly understood those needs and remained focused like a LASER on fulfilling them. For this role, the executive staff chose someone from the marketing side of the house: Me. I was promoted to Product Manager and once again found myself in the business of managing technology projects.
An Engineering Company Becomes a Solutions Company
It was my job to make sure that this time we built a product that customers wanted to buy; that we got it done quickly and right the first time. But by no means do I suggest that I was like the Lone Ranger, single-handedly saving the company: Everyone was focused on this goal. hard though it was, we all had to put our “engineering vs. marketing” mindset behind us and realize that we’re all on the same team and we all want the same thing: to build a product that will result in our acquisition by a larger company before Microsoft and Apple give away software that we can charge a lot of money for, for a short while. As the product manager, I just happened to be the one who’s job title screamed “It’s all on you buddy!”
My first act as Product Manager was to announce that I’d be relying on generally accepted project management practices (PMBOK) to describe the product and to manage its development, and that it was crucial for everyone involved to accept this methodology (This was my first experience with corporate change management. Thankfully, the executive staff were behind me, and engineering went along, though less than enthusiastically.)
While engineering got to work on the technical improvements that we already knew would be required, the marketing staff and I got to work on understanding the market’s broader requirements. We worked in very close partnership with Bell Canada (Canada’s largest phone company) to learn what a major TelCo wanted our software to do and to look like. We used their input - and the input of other TelCos - to create a Marketing Requirements Document (MRD) that clearly described to engineering what they needed to build. I used Critical Path Method software (Microsoft Project) to develop project schedules and to produce Gantt charts that showed exactly what needed to be done, when it needed to be done by, and who needed to do it.
From Nearly Bankrupt to Acquisition
Ultimately, our hard work and diligence paid off. Marketing and engineering put aside their differences and followed The Plan with LASER-like focus to quickly built a quality product that major phone companies all over the world were willing to pay handsomely for. Efficient Networks, a respected manufacturer of DSL modems and other networking gear, acquired our small company because they wanted to package our PPPoE software with their DSL modems.
Did this small, distressed company owe its ultimate success to the adoption of formal project management practices? Of course not. It owed its success to numerous factors, many of which, if different, could have led to an ugly outcome. For example, if we didn’t have a head-start on our competition because of our preexisting PPP software, the race with our competitors would have been much closer. Would we have failed had we not adopted formal project management practices? Yes, I believe we would have. PMBOK practices became like a dispassionate 3rd party mediating between engineering and marketing. The detailed descriptions of what the customer wants became an indisputable set of goals for engineering to design to. CPM scheduling set a crystal-clear roadmap that kept engineers focused on deadlines for completing each task in a long list of tasks that needed to be accomplished in sequence and on time. In an engineering playground like our company had previously been, “what if” was a time-consuming game that everyone loved to play, but staying on task was crucial to getting work done on time and CPM was a great tool to keep everyone focused.
In the end we all celebrated our successful acquisition on a 3-day cruise from Washington State to Victoria, British Columbia. It was a great way to relax together and to close the final chapter in this small company’s history.
Post Acquisition
I continued with Efficient Networks where I continued as Product Manager, and also was responsible for technical publications and software quality assurance, all of which required me to continue to rely on formal project management practices for our division to remain successful. After Efficient was acquired by Siemens AG, I was ultimately promoted to Director of Program Management, and was ultimately laid off as a result of the 2001 recession that led to consolidation in many companies worldwide, including Siemens. It was a good run!
After spending a year and a half abroad proudly serving my country in the Military Police Corps during Operation Iraqi Freedom (I had been a “weekend warrior” in the Army Reserve for several years), I had the good fortune to be hired by KLA-Tencor (K-T) to evangelize the virtues of formal project management practices and to oversee the deployment of Microsoft Project Server to K-T’s 3,000+ person engineering staff. I also successfully advocated for the formation of a Project Management Office (which I ran) and I developed and taught numerous project management classes in conjunction with K-T Corporate Learning.
Project management roles for which I’m well qualified:
- Project Manager / Program Manager for technology, real estate, and other industries
- Project Management Office & Project Support Office implementation and management
- Developing learning systems for - and teaching - project management theory and practice
- Project & program performance metrics design & tracking
Change Management Professional
While at KLA-Tencor, I achieved certification as Change Manager from ProSci Research, a recognized leader in the science of managing change. Change management is a structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state in a manner that minimizes disruption to operations and personnel by ensuring that a company’s most important resource (its workforce) are properly informed, motivated, and empowered. My change management training proved invaluable at KLA-Tencor while evangelizing and managing the transition to centralized management of complex engineering projects and programs. Also while at K-T, I had the honor of being a guest lecturer at Santa Clara University, where I discussed project management in the global enterprise.
 I’m well qualified to design and manage change initiatives like the following:
- Maintaining productivity and minimizing disruption during deployment of new technologies or new practices
- Minimizing the negative impact of change resulting from corporate
restructuring, downsizing, or acquisition
- Helping personnel understand and adapt to changes resulting from offshoring or outsourcing
I’m available to perform these services on a contractual basis. Contact me for more information, or to arrange an interview.
|
