Project Governance and Definition

We have all noticed how there is never enough space, money or time. It escapes no one and nothing. If there are two weeks to do a task it will take two weeks, if there is a $10,000 budget it will take $10,000 to do whatever it was. It is human nature. The goal has been set, it must be acceptable, so we strive to meet it. I refer to it as the "Garage Syndrome"—junk swells to fill the space in the garage.

It was a classical interview in all respects, except they kept asking, "Can you handle stress?" After while, I replied that on my last project gas mask training was a first-day requisite, meetings were routinely held in bomb shelters, there were written emergency evacuation plans, and uniformed men and women with M-16s were common sights on the city streets. That was stress. I should have known better. Stress comes from the unknown, the events in life for which we have no plans.

Maintenance does not belong in projects. Combining the two violates the definition of a project, mixes deliverables with opposing triple constraints, and sets the stage for scope creep. Maintenance needs to be performed by a dedicated group that can quickly implement changes. Project teams should focus on completing enhancements that will provide additional value to the customer.

A speaker at a recent conference asked the well-dressed audience, "When is the best time to listen?" As with most presenters' questions, there was a host of blank stares, a few people rustled in their seats, and the remainder diverted their eyes to their laps as if a sudden important message had appeared on their notepad. After a pregnant pause the answer came, "When someone is talking." A relieved, yet embarrassed, chuckle rippled through the suit-clad audience. The advice is a good start; however, listening entails significantly more effort.

Last Monday Mitch Lieberman invited me to a TweetJam on ITSuccess. My first reaction was, "What the heck is a TweetJam?" Google was of no help. All I could tell was that two of most prominent authorities on IT project failure were at the center of the meeting—Mike Krigsman and Phil Simon. The invitation was an honor. The result was summed up in my closing tweet, "@mjayliebs, that's one of the fastest hours I have spent in my life. Thank you very much for the idea and the invitation." It was one of the most educational and exciting events I have seen in years.

As mentioned last week, alignment is of the utmost importance. Achieving alignment, at first glance, is easier when the supplier works for the same company as the customer, say an IT organization delivering a new application to a business unit. However, from my experience there is little difference. In fact, exploring a vendor's world, where access to the customer is inhibited, sheds significant light on techniques to improve the customer-supplier relationship. Classically, vendors must wait for a request (RFP or RFQ) before they can get access to the customer. Exploring ways of "fishing up stream," as an eloquent account manager friend of mine says, is critical in improving project success. To understand this we need to review a couple of case studies on vendor success and failure.

The project sponsor is critical to project success, yet it is a role that is often assigned to a member of the organization with little knowledge or training in project management practices. This creates challenges not only for the sponsor but for the project manager. The organization suffers too if key members of the project team are not fully utilized, as valuable resources are wasted. In Strategies for Project Sponsorship, the authors address this challenge from all three vantage points that of the project manager, the project sponsor, and the organization. Based on their practical experience and solid research, they offer practical methods that project manager s can use to optimize the participation of the sponsor. They also offer clear and straightforward guidance for project sponsors on how to properly execute their duties and contribute to project success. Executives will gain valuable perspective on the organization s projects and key players. From defining the roles and responsibilities of the project sponsor to suggesting specific practices that maximize the working relationship between the sponsor and project manager, this book is the ultimate guide. Examples from real-world sponsor experiences, as well as tips, techniques, and tools, enhance its applicability and practicality. This book should be given to every newly assigned project sponsor, read and referred to by every project manager, and on the desk of every organizational executive as a reference.

I have always enjoyed cooking and rarely thought of it as a chore, let alone a project; however, when my wife became ill, I became the household chef and had to learn a new way to cook. Every evening was a project with varying degrees of success. Eventually making multi-course meals from scratch became easier. I used to joke that cooking Chinese food was two hours of chopping fresh vegetables and ten minutes with three blazing woks.

How many times have you heard someone say men are poor at multitasking? Well, that is probably a good thing, since multitasking is horribly inefficient. When I first said this in a presentation, people were shocked and took exception to the statement. After a few studies on the subject (summarized in a Harvard Business Review article), people are listening and agreeing. This should be nothing new. Looking at some of the more common methods to reign in red projects—Agile and Critical Chain—one premise they share is dedicating resources.

Projects build capabilities to meet corporate goals. If you are a CEO, you need to make sure your employees and vendors know what those goals are and how they fit in to the plan. If you are a project manager, you need to know the bounds of you project. If you are anywhere in between, you need to understand how all the pieces fit together and keep it all aligned.