Earlier this year I experimented with a small video about the importance of project goals. Quality and content were not great, but heck, it was an experiment.

I uploaded it again… enjoy!

BTW I have some great new videos lined up for you… all I need is time

Project Management Lessons from a Doomed Satellite Program

"Sunday's New York Times features a lengthy discussion of the factors contributing to the spectacular failure of the government's $4 billion spy satellite program. The project was ultimately canceled in yet it is clear from the the various participants that are quoted in the article that the effort was doomed from the start."

I don't love you, you don't love me, and we aren't a great big family

"All was going according to plan. Charge much less and get setup quicker than our competitors and then out deliver, out hustle, and out service expectations. The system begins to grow internally and one of two things happens… Scenario 2 is that the other department heads are terrified their peer will get all the credit and the system doesnt have every whim they ever dreamed up for their own department."

Six Views of Project Management Software

"There are many software applications that can help with project management tasks - but also many different opinions about what types of functionality you might want. We spoke to nine different nonprofit project managers to understand what software has been useful to them."

Agile Scrum Sucks (but so do the alternatives)

"No one likes project planning meetings. But, since project managers typically arent programmers dealing with the software each day, they need our input. If youre a product manager, trust me, your team will absolutely love you if you can get these chores down a half hour or less."

Management by Random Drop

Projects start up and projects get canceled and until now no-one really knew why.

The Spiritual Side of Project Management

"Having spent many years in both spiritual pursuits and project management, I have been intrigued to see how a number of areas overlap. Because spiritual principles seem to have a bearing on running projects successfully, it seems that there ought to be ways to communicate these spiritual principles to make them accessible and practical in the work place."

Or Not Every Single Process Component Is Effective Alone

Although I propose picking different techniques and process components from every method that you can lay your hands on, this doesnt mean that you can just pick a single piece from a method and hope it will work.I stress that an issue should be tackled by the introduction of a certain process component. A certain risk should be reduced. So sometimes this means that you have to add another piece in tandem with the technique you had in mind. They go hand in hand, and one without the other would be useless.

Alistair Cockburn provides a nice example in his article, Are Iterations Hazardous to Your Project?. Simply doing iterations in development without involving the users in the intermediate results is just wasting your time. Iterations are intended as a feedback mechanism; just iterating without the feedback part will make the techniques ineffective. In the words of Cockburn, Danger grows when the results of the iteration are not directly linked to delivering the product to the end user.

Or Different Circumstances, Different Effectiveness in Techniques

Traditional approaches (read plan-driven) will dictate that you first specify in detail what you want, before you start building the software. In the rigid approach, where you may not code anything before the design is approved, we call this the Big Design Up-Front.

We all know that the Big Design Up-Front (BDU) that we all used in the old days is dying out. Its purpose is to define everything that has to be built up front, so the process is nice and predictable. In the last decade, we found out that this is not such a good idea after all. The requirements change or are even unknown, so what is specified up front will be wrong, anyway. BDU, as a tool for feedback to the end users on what has to be built, is dead (or should be). The lean and mean validation process of short iterations and close end user cooperation provides more promising results.

However, feedback and validation to end users is not the only purpose of BDU. The design is also used to solve risks of miscommunication between parties and can be used as a formal document (as for contracts). If you have multiple parties that are not in the same geographical location but are working in parallel on highly connected system components (like interfaces), you might need a big design in the beginning. It will function as the main source for all parties to perform their tasks.

If you are going to work in a highly political, blameit-on-the-other-guy environment, youd better over your back and create a large document in the beginning describing what you are going to create, to be part of the contractual agreements.

Some professionals might have the tendency to take an attitude like, If they cant tell me what they want, we shouldnt even bother. In theory, you should be able to get at least close to 80% on paper up front. But sometimes it is wiser to support the users in their I know what I want when I see it mood just to be able to proceed and to get something useful. This is better than forcing large requirements and design sessions and having binders of documents that are mostly hard to read for end users (if they read them at all).

This is a sample of how techniques can be helpful under different circumstances. Even the old techniques everybody complains about (or defends heavily) serve their purposes. Also, the agile alternatives to BDU (iterative, close user involvement, and so on) have their risks (in no particular order, and without any intention of being complete):

• Miscommunication when there is a distance in team members in time or geographic location
• More vulnerability to changes in project team members
• Shorter planning horizon, so more difficulty in planning/estimating costs for the whole (not every customer can handle this)
• Risk of requirements inflation (end user communicates directly with developer)

For the person who wrote: "When looking daily at the remains of my planning I feel like an FBI Profiler, or more appropriate, a Project Profiler.", the latest article by Malcolm Gladwell is a welcome wake up call.

I am the person writing about the Project Profiler. And Gladwell, author of the The Tipping Point and Blink, writes in Dangerous Minds about the effectiveness of FBI Profilers.

"In the mid-nineties, the British Home Office analyzed a hundred and eighty-four crimes, to see how many times profiles led to the arrest of a criminal. The profile worked in five of those cases."

"The fact is that different offenders can exhibit the same behaviors for completely different reasons…"

"Youve got a rapist who attacks a woman in the park and pulls her shirt up over her face. Why? What does that mean? There are ten different things it could mean. It could mean he doesnt want to see her. It could mean he doesnt want her to see him. It could mean he wants to see her breasts, he wants to imagine someone else, he wants to incapacitate her arms”all of those are possibilities. You cant just look at one behavior in isolation."

In the end he concludes that its effectiveness is only in combination with other disciplines of the FBI. It is never the Behavioral Unit alone that solves the crime.

But I will be back!