How your Obeng Project Type affects your Planning, Methodology and Leadership

Knowing what kind of project you are working on can help you work out which planning method and software methodology to apply, as well as what management strategy to use. Once you have categorised your project into one of these four types, you will improve your expectations about the timescale and velocity. Not knowing about these project types leads to confusion about the project direction and pace, which can be demoralising for staff and leads to misunderstanding by customers, management and other departments.

The trend in the last 20 years has been to apply Agile methodologies to all projects, but this Feabhas video explains why that isn't always a good idea. (The click-baity title isn't what it first appears).

I'd like to expand on the video by looking at the relationship between these four project types and the appropriate planning and execution strategies.

These four project types were described by Eddie Obeng, who said

"As a project manager, as a business, we have to understand the type of project that we are working on because each type of project has a different management strategy associated with it. More specifically, we have to apply our effort in different places and in different ways and spend our money differently depending on what our problems are."

The "Painting By Numbers" Project Type

• Customers are very sure about what is to be done - goals are clearly defined.
• Implementers are very sure about how to do it - tools are well known to developers, they have much experience in their complete toolchain and delivery process having delivered many successful similar projects before.
• The organization has been through this type of project previously and has all the required skills. The process is mature.

Waterfall project planning using Gantt charts works well for "Painting by Numbers" because each task can be estimated accurately at the start of the project, the dependencies are known and there is very little chance of surprises causing late delivery. Slack can be built in using experience of previous projects so that there is a high probability of on-time completion. There should be little doubt that the final product will meet the requirements due to the team's experience.

These sound like boring, crank the handle of the sausage machine sorts of projects where nothing much interesting is done, so the only factors for management to adjust is resource usage reduction or increased speed. A certain type of software known as CRUD is likely to fall into this category. Talented developers won't want to stick around long for these sorts of jobs if they make up the majority of the workload. But they are no problem if they make up only a background, small proportion of the workload, which everyone accepts is necessary to keep the business rolling.

The "Movie" Project Type

• Customers are not sure what is to be done, in precise terms. They have a general idea, but leave the specifics up to the implementers. eg "We want a sci-fi film with a major battle between warring planets". Or a software product example "We need to be able to produce high quality graphics for advertising posters".
• Implementors are very sure about how the project is to be done - tools are well known to developers, as above. The developers are not about to use some new technology for this project.
• The organization is clear about the methods and has the skills.

Most of the effort in this type of project is defining the 'what' is to be done. It requires the Product Manager to liaise between the customer and the developers.

Agile methodologies work well for "Movie" projects because the customers need to be involved with the implementors while defining the 'what'. Multiple iterations will be involved, leading to refinement. Although it might be thought that Waterfall could be used for Movies because each task can be planned and dependencies are known, that leaves out parts of the Movie project which require multiple iterations such as story development, costume and set design, scoring, special effects and final editing. I doubt that any of these pop out right first time for any movie done with an eye for quality.

These types of projects are the bread-and-butter of mainstream software today such as mobile apps, web apps, web sites and services, and desktop software. Some embedded projects can be seen to fit this type if the project is based on pre-existing libraries or modules, but for many this is not the right project type.

The "Quest" Project Type

• Customers are sure what is to be done - goals are clearly defined. eg "Make the number 1 game in the App Store"
• Implementers are unsure about how the project is to be done - may not know if tools exist which can help, which ones are best suited, who in team is best placed to learn which technology. Some learning is required and therefore some uncertainty in whether the goal is achieveable as well as in the timescale.
• The organization may not have the skills.

All of the effort needs to be spend in the 'how'. The implemention is likely to be novel and risky.

Some embedded projects fit the "Quest" Project type such as when a radical new approach is needed because all existing attempts have been unsatisfactory. As Feabhas says, 

there may be questions that we need to ask but there are very few unknown unknowns in that ... In this case, having a customer representative on site or writing user stories is not going to help us. No amount of requirements analysis is going to give us a solution ... we need prototyping ... we need to explore solution ideas, we need to try new technologies.

Many embedded projects fall into the "same but better" i.e. improved performance, which is about more than just bumping up the clock speed or the processor. This also requires a "Quest" approach. In which case, note that applying the Agile, or "Movie" approach isn't going to work because the customer only has knowledge of the problem domain, not the solution domain which is where the work needs to be done.

The "Lost in the Fog" Project Type

• Customers cannot give much guidance on what they want from the project, they might not even be able to say what sort of product they want. e.g. "Society needs autonomous vehicles"
• Implementers do not know how to achieve the project aims. It is not immediately apparent to them that any technology that they are familiar with will help.
• The organization is attempting to do something that has not been done before.

This is a research project. Time has to be spent investigating many technologies, not all of which will be applicable to this project, so management has to accept there will be time "wasted" on blind alleys. But is that time actually wasted? it might prove useful on other projects in future, so should be seen as investment and advance work on products which could prove to be significant.

This type of project is naturally resource intensive - it is best done by increasing the size of the team so that several leads can be followed up simultaneously rather than serially. Learning about each new technology takes time before it can be evaluated for applicability to the project. Many different development kits and tools may have to purchased for experimental usage. It is quite likely that the developers will lose track of where they are going entirely. Clearly, managing this requires a completely different strategy to the other three project types.

Management of this type of project requires someone with a vision, who can tell which ideas should be pursued, can tell when the project is going in right direction and when it is not. When to leave the developers alone for a bit to try out wacky ideas, and when to rein them in.

Feabhas says

"Lost in the Fog" projects are when breakthrough technologies can occur, you can move in an area that other people can't get to ... If you have strong leadership and leadership with a strong vision, these can be really powerful projects.

So they certainly aren't a project pathology but they may not be what management wanted from the project.

Developers will be very happy to be involved in "Lost in the Fog" projects, but companies can rarely afford that full time. However, it can be done as a part time strategy, such as Google's famous 20 percent time working on your own projects which led to Gmail, Google News, Maps, and Adsense.

Using this knowledge

It's now apparent to me that my historic projects which didn't get off the ground were the "Lost in the Fog" projects, where it wasn't clear what the goals were and it wasn't clear how known technologies could get there. But from this analysis I can now see that personal knowledge wasn't the only barrier to sucess, that these projects need the right sort of support outside my control.

I think developers are attracted to "Lost in the Fog" projects because of the possibility of inventing something radical, but it is a challenge for more established companies. It's a high risk strategy taken more often by startups, and it seems that as the company gets bigger they are less likely to attempt them. In 2013, Google's 20% time reportedly ceased.

You can use the knowledge of whether you are on a Movie or a Quest to help justify the involvement of a Product Manger or to spend the money on engineering time and tools.

If your Project Manager insists on using Agile methodologies for a Quest type project, use this analysis to show that time and effort are not being spent in the right place - see the Feabhas quote in the Quest section above and show them the video.

If too much of your time as a developer is taken up by Painting By Numbers projects, then it will be worth investing that time instead into automating it. Which of course is a seperate project which will not be the Painting By Numbers type.