Projects Are About Humans. We Help You Deal With That.

There is not one way to make a great lasagna. Of course the basic idea is always the same, but depending on your taste, cooking skills and available ingredients you can have a lot of variations. Some use all fresh ingredients, make the pasta from scratch and spend several hours in the kitchen. I buy prefabricated ingredients and whip it up in several minutes. Both lasagna, but both very different.

Photography by RustyBuckets.

From lasagna to software projects is a stretch, but I’ll take my chances. Although some books may cause you to believe that there is one way to perform a software project, believe me, there isn’t. There are many more ways. Just look at the number of methods that are available: Prince2, PMP, Scrum, Lean Project Management, and if you combine that with the software development methods that exist, you have plenty of combinations that may be useful.

In recent years some heated debates are in this industry about the “right” method. In one corner you have the traditional “plan-driven” camp, and in the other the new rebels, the “agile” supporters. In essence the first group believes you should define every step that has to be performed in detail up front; the actual task, the timelines, the organization and the procedures that should be followed. This will increase the predictability, stability and high assurance of the process and the products it produces. You plan, you provide everyone the orders, and make sure everybody sticks to it.

The fact that a software project is not that predictable as everyone hopes, and the cost for this enforced structure is a higher overhead (a lot of time is spent on creating supporting products like plans, reports and documentation, stuff that is not or hardly used in the end result) sparked some new ideas about the “right” approach for software projects. Agile methods use the concept of “just enough”; just enough structure in the process to keep things going in the right direction, just enough supporting products like small plans, short reports, and, most importantly, agile approaches assume things change. According to this philosophy it makes no sense in trying to prescribe the future in plans, as the situation will change anyway. Instead they focus on creating a process that easily adapts to the situation.

Both camps say there approach works. Cannot argue against predictability and stability. Adaptiveness sounds also very wise. Is one of them lying? I will definitely say “no”. Every method has its merits. Every approach has a sample project where it worked very effectively. But not every project is the same. Different people, different tools, different end result, different project constraints, different circumstances.

Different circumstances require a different approach. If you need creativity to solve a problem or to create a design, you need an easy going, stimulating approach; if you are running towards a deadline to get towards production, a rigid, centralized controlled environment is more the way to go. Depending on the environment and general circumstances a project manager should construct a process and organization that serves him or her best. In the ideal situation you should be able to cut and paste a method together that suits your situation, use proven approaches in the exact situation you find yourself in.

Key question is “what make up the circumstances of a project?”

Photography by SideLong.

First of all, the desired end result of the project is a main factor. Creating a navigational system for a space craft would be very different from a application to organize your recipes. Not only would the application be different in size and complexity, also the requirements on stability and reliability would differ enormously.

Secondly, without hesitation I would say “people”. In my personal experience all major problems concerning projects are caused by human stuff. It may be just the level of skill or knowledge of a project team member, but don’t think too lightly about the impact of cultural and political influences on your project.

To give you a better idea, Boehm and Turner in their book “Balancing Agility and Discipline: A Guide for the Perplexed” have defined 5 dimensions that should affect a method selection:

Critically: if the end results has a failure in it, what would be the cost? The scale ranges from just the lost of comfort to the lost of many lives.

Personnel: the level of the skills of the project team members.

Size: the number of personnel involved.

Dynamism: the number of requirement changes per month (what is the level of how good people can define the requirements)

Culture: are people used to handle change, take their own initiative, or are people used to order, to have there work laid out in plans for them.

I list them, not to say that these are the only ones. Just to illustrate what kind of aspects can influence your choice to choose for a certain approach. And you have to choose. It is not only that the right approach may be more effective, it holds also true that a wrong method can sink your project to the bottom of the corporate ocean.

Letting people make there own decisions in an organization where this is not stimulated by there culture may leave you with indecisive team members, or worse, just decisions that will make them popular, that are socially acceptable.

It may seem that more roads lead to Rome, but don’t forget that it is actually a maze.