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.

In daily talks and presentations, I am often asked what the most common reasons are for project failures. I usually turn the question around and ask people what they think. It is a fun exercise and people list a mixture of symptoms and sources. As mentioned in the previous blog, one must drill past the symptoms and get down to the problem itself. It is my firm belief that most project problems are rooted in the people, however people are creatures of habit.

It is common that when I am called into fix a red project to have management assign all of the projects ills to one problem. As of yet, I have to see such a project. There are multitudes of problems deeply embedded in the organization and the project team to make a project truly crimson. Managers look at how the problems manifest themselves, skip diagnoses and assign blame. Prior to getting to the point of calling an outside party, they have tried to fix the issues by attacking these symptoms. This only makes matters worse and the project becomes a deeper shade of red.

Reading an article the other day, the author was lamenting on how Project Managers were under educated and needed to know more about earned values analysis, risk probability determination, finite schedule development and other tools that make a Project Manager great. She was arguing that certifications, like PMI's PMP^® certification, needed to have more testing on those subjects.

The term 'Inception Phase' is often used to signify a project's beginning. Isn’t it really the birth? There are many similarities between a project's lifecycle and this familial analogy.

Inception happens much earlier with a glass of wine, maybe two. That first thought, “Hey, wouldn’t it be neat if we had a…” Complete the sentence to fit the situation. It is at this point that the ball gets rolling, so to speak, and someone decides to invest some time to explore the possibility of making something happen. The originator courts the business manager, selling the concept of the idea, until there is approval to move forward. Voilà! It is conceived. Someone commits to carry and nurture the project, allowing it to incubate and mature into a viable form that can properly benefit the organization as a final product. After the proper gestation, the project is born and has a team assigned. This is the transition that many methodologies errantly label inception.

The Guidance Team, PMI Portland Newsletter, September 2009

Before a project becomes a project, significant work has already been performed. The project has already met a series of qualifying measures by the customer to justify its value over other initiatives that were proposed. These are business decisions to continue with the initiative. This is the real inception of the project. The projects that survive this vetting process are based on the resolve, passion and determination of people in a business unit.

Assigning a Guidance Team to work in the business process for selecting projects greatly reduces the communication issues as the project gets transferred into the hands of the supplier. The article on Page 11 of this newsletter, written by Todd Williams, describes how this team works.

Many companies have some form of a portfolio management group to manage their projects and their backlog. The projects they govern range from network pulls to new software development. However, most use only one methodology to run these projects. It may be waterfall, Agile, Critical Chain or some other process. This is analogous to having only one knife in the kitchen. Anyone that has cooked more than a few meals realizes that a table knife is insufficient for all your kitchen needs. It purees tomatoes, cuts meat poorly, fails at filleting fish and suffers as a steak knife. There are hundreds of knives, each designed to do some specific job. As with many jobs, some tools are better than others are for certain tasks.

Using Twitter as a Business Tool

Bo Bennett and Ryan Levesque at Twooting.com interview Todd Williams on using Twitter in business.  Todd discusses his use of twitter (@BackFromRed) to promote the Back From Red blog and his volunteering at the Southwest Washington Blood Program (@SWBlood).

"Technology... is a queer thing. It brings you great gifts with one hand, and it stabs you in the back with the other." This quote, delivered by C. P. Snow, is one we should all live by. Mr. Snow was a physicist, a novelist and a bit of philosopher. Technology brings about great benefits that many of our projects rely upon. We are using it right now. However, take pause to reflect on how technology is also our nemesis. It haunts our projects with its false promises and lures us into implementing superfluous functionality.

Yes, I am on that soapbox. Ensuring that maintainability and adaptability are part of a system is a "best practice," extensibility is not. To the extent that a highly structured system is extensible, that is the end of any commitment to building for the future.

Adding hooks and stubs for something that may not happen, confuses and clutters the design of the resulting system. Building and running prototypes wastes time. Making a system extensible adds significant undefined scope. The reason is that no one knows what the future will bring. Furthermore, how can it be tested if the systems it is interfacing with are not defined?