In the last post, we listed what makes a project complicated or complex and the skills required to manage these projects.
In this post, we will go into more detail and set the scene for later posts about what makes a project complicated.
In/Outbound Dependencies
In simple terms, a dependency is where you rely on someone else to do something first so that you can do something.
In complicated projects, there can be inbound and outbound dependencies.
An inbound dependency is where your project needs someone else to do something first. Inbound dependencies create complications as you must stay on top of when things will land and how this influences your project.
In contrast, an outbound dependency is where another project requires you to do something first. Outbound dependencies create fewer complications as you are not reliant on their completion; however, this could create complexity as you may start to be influenced by other projects or stakeholders to prioritise the delivery of certain things – We will discuss this in a later post about complexities.
Multiple Teams
When you have one team working on a project, it is simple. Right?
Everyone knows what the goal is; you speak to them daily, they raise concerns, you agree to corrective actions and get on with delivery. Right?
The project’s focus is relatively easy to articulate, and you can check that everybody understands it.
You can speak to the client; they can provide feedback and direction directly to you. You can then priotise the input with the team and ensure they will focus on what needs doing right now.
The feedback loop is quick.
As the number of teams involved in a project grows, it will likely get more complicated.
Will the additional team have its own culture, dynamics or working method? Will their focus be the same as yours? Will they be juggling priorities from many other masters? Will they be readily available to discuss your priorities?
Add some more teams in, and the process becomes exponentially more complicated.
The feedback loop is slower and more challenging to correct.
You will need to build a good relationship working relationship to succeed. We will go into more detail on this in later posts.
Technical Challange
A technical challenge can be solved by following a process. You will need expertise and may fail (or learn). Still, by applying expertise and following a process, you should succeed. For example, baking a cake is a technical challenge that involves following a recipe but may result in failures, to begin with, while you perfect your technique.
A complicated problem may be difficult to solve; however, it is possible if you have the right expertise.
You can design a process to understand the problem, often called a Discovery Phase, and then apply the expertise in design and test a solution. This solution is often called a Proof of Concept, progressing to an Alpha, Beta, and Minimum Viable Product release.
Repeatable Process
Following on from explaining a technical challenge, the process you derive from solving the challenge should be able to be documented. By breaking the method down into smaller steps, you can create a repeatable process that someone else can follow to complete a task. For example, creating Cloud Services is complicated and requires expertise.
Still, you can follow documented processes that explain how to deploy and manage these services. A critical skill here is attention to detail, which enables teams to follow a process.
Following on from explaining a technical challenge, the process you derive from solving the challenge should be able to be documented.
By breaking the method down into smaller steps, you can create a repeatable process that someone else can follow to complete a task. For example, creating Cloud Services is complicated and requires expertise. Still, you can follow documented processes that explain how to deploy and manage these services. A critical skill here is attention to detail, which enables teams to follow a process.
In some cases, you cannot document a process for successful delivery. Complex factors may render a repeatable process futile — for example, launching a new product to market. A more intuitive approach is required.
You can research the user needs, design, build and test
the solution to meet these needs but fail to gain any traction after a launch, even though you may have a great product. There could be several reasons for this, often beyond your control.
Complex factors that impact success can render a repeatable process ineffective. In this instance, a framework or rough guide is more appropriate – we will cover this in later posts.
Summary
Recognising that a project is complicated enables you to use the best skill sets and tools to ensure successful delivery. You can create a team with the required expertise to work in an environment with dependencies, other teams, challenging outcomes and attention to detail that success demands.
In later posts, we will detail the required skills and tools you can use to deliver complicated projects.