At Reason, it's our business to deliver successful digital projects. Kicking off is the most important part of the journey, don’t get it right and you are playing catch up and putting out fires from day 1. Throughout the years we have learned that the biggest challenges at the start of the project are inevitably human shaped ones. In this post I outline 3 of the biggest learnings we have, and what we do to overcome them.

1 - No one has worked together before (a lot of the time)

Not always the case, but quite often project teams, client teams, stakeholders have never worked together before. This is one of the biggest influencers of project success but never seems to be addressed. When we talk about risks we discuss dependencies, scaling issues, complexity but above all we should be addressing that success of any project is 100% reliant on the team working well together.

"success of any project is 100% reliant on the team working well together."

2 - Everyone has a different opinion on how long things should take

At Reason we champion Lean, Agile, autonomous cross-functional teams as the primary catalyst in digital transformation, the nature of these teams is we are all individuals and all have varying expertise in different areas. We have a natural inclination to gloss over what we don’t understand and can therefore find it hard to believe that certain aspects of a project can take so long. We need to build clarity into the amount of work that goes into each part of the project as well as build up the level of trust in our team members expertise in their chosen fields when building software, like in any team activity you are only as fast as your slowest member.

3 - Our memories are crap

How many times have you walked out of a meeting 100% certain that everyone was in alignment and agreed to everything, only to find out everyone still has conflicting views. We are tuned only to remember what we deem important in conversations, our brains have evolved to remember spatial things not conversations, spreadsheet line items or jira tickets - Fun Fact competitors in the memory olympics use a process called the memory palace which uses visualizations with the use of spatial memory, familiar information about one's environment, to quickly and efficiently recall information.

At Reason we are hyper conscious of the human factors of any project and are constantly exploring ways to ensure an efficient and human shaped start to projects. Below are some of our approaches that we have been using - special thanks to Greg Morell and the team at Agency Agile for being a huge influence in this.

Pull, not push:

Brief’s don’t help, they are created in isolation of software delivery and generally not written by the people who will be delivering the project. So rather than take a brief, we ask the team to author co-author a vision by interviewing stakeholders and people with the knowledge. Using a simple 5 step framework of Vision, Key Behaviours, Platform & Approach, Questions, Success the team authors the brief that is then presented and built on in partnership with the client. The principles behind this are:

• They are written by the team, not an individual
• Everything is discussed
• If you say something, you write it yourself - as TLC say ‘no scribes’

We use the output of this as a project charter, something that helps guide us throughout the project. It is an emotional contract that the team and stakeholders buy into.

Allow the team to build the scope

One of the things that has never sat right with me about ‘agile’ software development is the idea that we start with a backlog, this fully fledged prioritised thing that lives in Jira/Trello/Spreadsheet just appears out of mid air and we can get to work. More often than not this is created using a bucket of requirements and much like a brief done in isolation of the team.

Starting with the project charter and vision the cross functional team responsible for delivering the project begin to note down all of the capabilities required to deliver this vision. We then allow the team to organise these capabilities into a logical grouping, logical for the designers in the room, logical for the engineers in the room and logical for the stakeholders in the room.

One by one (or in pairs) team members draw out success criteria for each capability, what exactly does this have to do in order for us to deliver on our vision.

Together now, we have built a backlog that is full of goals (epics), capabilities (user stories) and success criteria for each, all agreed, all created by the people responsible for delivering software.

Make it real

Remember earlier when I said our brains were evolved to remember visual and spatial things? That is why we use physical cards to build our backlog, the team is able to create a physical picture in their mind of what the project entails, and as the project moves forward we will be remembering discussions and scope in relation to where they were on the wall rather than what row or column it is in the spreadsheet.

We use a physical scope line to move success criteria, user stories and sometimes even epics out of scope. By making this evident in the world there is no confusion about what is in and out of scope. Stakeholders, team members - anyone can do this, but to move it below they line there has to be justification.

Be transparent

Remember the risk that everyone has a different idea about how long things should take, this is no more evident than with stakeholders. By walking (or even better creating) these physical backlogs with stakeholders there is a clear understanding about the level of effort and the complexity of everything.

This transparency goes from estimation to cost, as a services business we believe in being 100% transparent of the cost of each activity to the client. It allows us to have conversations along the lines of ‘if this was my money, here is where I would spend it’.

Using this process might mean you are a little bit slower in kicking off a project, but what is a few days if you are talking about the success of a project. We call this ‘start slow to move fast’.

Whether we are running a 4 week concept project or a 6 month scaling programme this approach ensures success.

‍