Even though autonomous teams and continuous & iterative development are the new norm everywhere, working with schedule, scoped list of things and/or limited budget means some kind of structured approach to achieve the goals you’ve set.
Were it called a project or something else, I believe there are still some key things to be considered in order to have a successful end result. There are four key themes to be followed for successful project deliveries: Why, What, When, How and Retrospective? Let me open them up a bit more.
1 — Why
I believe the biggest motivation to do things is to know why. It’s not enough to know what should be done and when and to whom. But also how the customer will benefit from the outcome. State clearly what is the objective of the project. You can also use team related objectives too.
”People don’t buy what you do, they buy why you do it — Simon Sinek”
In one of my projects we did mobile apps for customers where our team internal objective was to get knowledge and experience of the used tech. Our developers took some time to look for and learn about different methods to master the new technology. That lead to results which were initially estimated to be impossible. And the what’s noteworthy, is that we did not have any strict training plan in the project. People wanted to master the tech by them selves to benefit it in the future as well.
2 — What
By identifying in written what is to be done, makes all the difference. Write down the ready end result or vision where you target to be. How do you know when you hit the goal, if you don’t have an idea what it should be? Draw the big picture for your team.
”How do you know when you hit the goal if you don’t have an idea what it should be?”
Communicate to your team who is the customer and who are the other stakeholders. In addition to the big picture, business requirements available that anybody can understand. And be open about the available budget too.
The more your team knows the more they can be self-directed and innovative to achieve the goal, instead of just following blindly your orders.
3 — When
This is often one of the trickiest part during the planning. How do you define when the project is ready? Quite often first we think of time. And that’s usually the first thing you ask from the development: ”When will the product be ready?” And they answer back to you just as meaningless: ”It’s ready when it’s ready”. Within continuous development it is even more crucial to define what ’when’ means.
”It’s ready when it’s ready”
Create preliminary roadmap when are your deadlines and when would you like to have something released. Define criteria to releases also. If you are e.g. creating a MVP (Minimum Viable Product) it is important to have common understanding with the customer what are the things bringing necessary value for the user. When those criteria are met that’s WHEN you can release from your project.
4 — How
The fourth element describes the details how to execute the work. This is what a project plan usually is. If you google up ”project plan” you’ve got all different kind of gantt chart examples. But I truly believe that you should go through What, Why and When stages before rushing into filling up the documentation called project plan.
When you have solid groundings it is much easier to identify and agree the tasks needed to be done and what kind of iterations you need in order to achieve the big picture. Agree also clearly who is responsible of which task and how the progress is followed up.
”Risk management is important ingredient in the secret sauce to successful project!”
Many of the projects get stuck on firefighting mode. I don’t think it is because of poor planning, but it is more of a lack of risk management. Trying to come up with list of potential risks in the beginning of the project is one thing, but actually running risk management throughout the project is an art of its own. When you list potential risks and make a plan how to mitigate them weekly, it gives you heads up to be proactive instead of fire fighter. Risk management is important ingredient in the secret sauce to successful project!
5 — Retrospective
Those were the rule of four key questions. But I would add one more step to the end — retrospective. When your project is over or you’ve made your release, ask for feedback. How satisfied your customer or user is? How satisfied are your stakeholders? What would you do or have differently? Go through the feedback with your team and work together on lessons learned. What you don’t measure, you cannot improve.
”What you don’t measure, you cannot improve.”
I don’t think it matters so much if you have a project or iterative development, these are still the things you should be aware of and gone through together with your team. Instead of just filling up the corporate template write down what you really can stand behind.
It’s easy to think that you’ve covered all of these, but if I’d ask from your team members, would they know what they are? Could I find these in written somewhere on your team site?
Spend little time with these five headlines. I ensure you will have much more successful end result.
Discover more from Tassberg Consulting
Subscribe to get the latest posts sent to your email.