So far in this series we have discussed software development methodology within teams using Government Digital Service. We have also looked at conflict in teams and the importance of setting project scope.
Now I would like to offer some suggestions on processes or techniques that could be embedded into teams, to allow for a smoother project delivery. The overwhelming theme across this series has related to conflict, whether that is within teams, or with stakeholders. If we were to attribute a cause to the conflict, it would be that within projects there is often:
- Overlapping and unclear responsibilities
- Pressured timescales
- A lack of agreement or understanding between stakeholders and the team
In the last instalment we discussed project scope and techniques that could be used to set direction. This is important because it clears confusion, which can add to conflict. However, even in a project with a well-defined scope, there will still be unnecessary conflict within the team, when timescales are tight. Therefore, having a plan is important.
Have a plan
We know that for every feature being developed, there must be clear user needs, and substantial user research. There must also be design work, whether that is in the form of interactive prototypes or otherwise. In addition to this there should be an element of analysis and requirements engineering. Then there should be development, including testing and deployment.
One of the issues that we highlighted previously is that there is often a fixed deadline. In government projects, the reason for this could be that there is a legislative date that policy must be implemented by. Digital teams are usually required to have at least an MVP of a product by this date.
Now that we know when the project must be implemented by, and the phases that the project must go through, we can start to understand which tasks need to be completed. I believe that constant collaboration is important, therefore creating tasks based on the product roadmap is a good team activity.
Once the tasks are understood, the team can start to think about the complexity or time involved in completing them. They can also think about some logical ordering. e.g. Do we start with analysis, to feed into user research questions? Or are we more likely to gain quality insight through user observations? Do we sketch some ideas, or have a go at a more defined interactive prototype? I believe that we should be involving the developers and testers early on to ensure user needs and requirements are understood. It’s also wise to get early estimates from them to ensure deliverability.
Obviously, a plan should be evolved the more you understand about a project. It’s also important to bring stakeholders such as the Product Owner along the journey with the team, in order to ensure priorities are correct. On the other hand, if requirements are too large to deliver, it’s beneficial for the Product Owner to have constant visibility so that they can re-prioritise.
How our plan built NHS Jobs
Below is an example of a plan we created at NHS Jobs, when delivering the ‘search’ element.
Get T-shaped…
When we plan for activities such as analysis, user research or design on a project, the need for activities to be completed might outweigh the skilled resource on the team. When timescales are tight it’s not practical to continuously hire, especially because it takes time for individuals to be upskilled. It’s also difficult to predict upfront the exact resource need. Therefore, it’s beneficial to have a T-shaped team.
Sorry to use a buzzword here, but I’m a strong believer in individuals bringing more than a single skillset to the table. Of course, having a team of experts is useful, people should specialise in certain areas too. However, naturally whether it’s a soft skill, or a learned craft, people have multiple strengths that can be valuable. On a day to day basis, you may utilise your specialism more frequently, but in a fast-paced environment, it’s important to cross-skill and dig in, helping out where necessary.
I simply believe that it is very important to develop additional capabilities, to make you a more rounded team member.
Above is a demonstration of what I mean T-shaped, using my skills and experience as an example.
I trained as a Business Analyst, and I have been a Business Analyst on numerous projects. Therefore, my specialism is in Business Analysis. However, whilst I have always been recruited as a Business Analyst, I have been heavily involved on the product or delivery side on multiple occasions.
This has developed my product and delivery capabilities, which I have been able to use to either prop up, or compliment projects that could benefit from them.
Who is in charge?
As I’ve previously mentioned, this series of blog posts originally took the form of a presentation to the Senior Leadership Team at Difrent. For that session, I listed many of the projects I’ve been involved in over the last five years, across a few different organisations.
A couple of themes that continuously appeared was that projects either had complex stakeholder structures, or complicated stakeholder relationships.
I find that stakeholder management is a natural process, largely built on trust and the concept of a shared vision. However, there are techniques available to help develop a better understanding of stakeholders too. One of the techniques that I’m particularly keen on is the Power/Interest Chart.
There is a grid. On the vertical axis you have the concept of ‘Power’ and on the horizontal axis there is ‘Interest’. You would think of all of your stakeholders and try to allocate them into these categories. Where stakeholders have low power and low interest, you watch them with minimal effort. Where stakeholders have high power and low interest, you keep them satisfied. Where there are stakeholders with high power and high interest, you manage them closely. With stakeholders that have high interest and low power, you keep them informed.
I’ve had a go at creating a power/interest chart based on some standard roles within a typical technology organisation below. However, if this was to be used in a real-life scenario, it would be worth calling stakeholders out by name.
People of Difrent
So far, I have largely provided my own views on techniques that are useful when successfully delivering projects. In addition to this, I asked a number of well experienced individuals working at, or for Difrent to share their techniques too:
“I find that design thinking is a fundamental part of any delivery, especially in an agile environment. This will ensure user-centred, safe to fail environments, as well as outcomes that meet and exceed user / client needs”. Darren Lynch (Delivery Manager)
“As a Scrum Master, my techniques to deliver projects successfully is all about people and mindset. They often revolve around coaching, getting to know the team, motivating the team and constant collaboration. This creates an environment and culture for the team to grow, learn from each other, share, thrive and have fun”. Richard Haydon (Scrum Master)
“I use methodologies that I have been trained in or have learned as a framework rather than the absolute, unwavering rule. This gives me the ability to take a step back and think of what would be best for the project and adapt, rather putting in a raft of time-consuming ceremonies or practices that would be unsuitable or wasted time”. David Clark (Delivery Manager)
“One of the simpler things I like to do is question the activities of the team, to check that what we are currently doing is progressing us towards where we want to be, rather than fixing something we’ve just found. I also find old school techniques like five whys really effective in understanding what outcome we are trying to deliver? Rather than what shiny thing can we do with this problem”? Daniel Leakey (Business Change Director)
“For me creating situational awareness is key before even thinking about delivery. Using a technique like Wardley Mapping allows me to understand the landscape and start to explore which approaches to delivery are best in a way of fit, whether this be agile, waterfall, lean or a combination of all”. Rachel Murphy (CEO)
I’ve hoped you’ve enjoyed this series. I love to talk about this kind of stuff, so if you want to chat, or have any questions, just drop me a message!
Charan's Blogs 