Be on top of your game — Planning over prediction
Introduction
Do you speak Welsh? Because if you are privileged enough to do, you would know that Cynefin is a Welsh word for habitat. It is also the name of the conceptual framework used to aid decision-making, created in 1999 by Dave Snowden when he worked for IBM Global Services. a “sense-making device”, as many describe it, that offers five decision-making contexts or “domains” to help managers identify how they perceive situations and make sense of their own and other people’s behavior.
According to the Cynefin framework, complex projects represent the “unknown unknowns” and as there are no right answers for their solution, the best way to handle them is to experiment and retrospect.
Over the past few months, we have been dealing with a complex project that needed involvement from many departments and teams within the company. We have experimented a lot, so we decided to share the solutions that best worked for us, as most of them will be most probably revisited in the future.
The project
A purely compliance project that needed the involvement of many departments and people. The changes needed affected our systems, our site and applications, our operations and our day to day processes. The scope of the project was to comply with the new regulation for our major market aiming to be competitive and compliant in a short timeframe.
The who’s and when’s
Firstly, it is imperative to define distinct roles, who should participate in each stage of the project, and set responsibilities. Once this is set, smaller teams can be set groups and focus on their tasks. Now, let’s explore the roles and responsibilities that worked in our case:
Key Stakeholder (decision maker) The person with the clearest view of the bigger picture throughout the company; as many people will have to be involved in a large-scale project, it’s that person to make sure that all angles are covered and include anyone needed. The key stakeholder is the one who makes the final decisions and ensures that it is aligned with the overall strategy of the company. This is strictly a one-man role as, when many key stakeholders participate with the intention of controlling basic functions of the project, there is a high chance of putting the project in jeopardy.
The person from tech — Tech should be always involved, as soon as possible, to interpret the projects requirements to achievable specifications based on the technical limitations. Business analysis processes can be time-consuming and require multiple meetings and discussions until the solution that best fits business needs is found. In our case, two product/tech savvy people were selected, having facilitated the process of splitting the tasks to the relevant technical teams and avoiding back and fourths.
The person from the rest of the world — It is equally important to allocate specific people from other departments of the company whose operations are affected by the project. In our case, a single point of contact helped us by responding to our inquiries and giving input with detail and accuracy. Different departments like Operations (Customer Service, Payments etc.), Compliance, Marketing and Security had to be involved in the project. The direct feedback of one single person, through short and complete discussions, contributed to the precipitation of the project and to define a user story as ready (DoR) earlier in the process.
Communication
If not the number one success factor, then surely an excellent recipe for disaster; in other words, having an effective communication plan is as important as the project’s blueprint. You can never get it right from day 1, that’s for sure but hey, this is Kaizen, the house of agility and trial and error processes, so keep trying. In our case, three communication channels were the most crucial ones.
Stakeholders — Keeping stakeholders in the loop through regular sync/feedback meetings, ad hoc chats/calls for making quick decisions, and keeping Q&A logs open to everyone who participated in the project.
Development teams — As Kaizen’s software development life cycle follows Scrum principles and ceremonies, we had to adapt project’s needs to our business as usual. We optimized existing processes with additional communication meetings among all scrum teams involved. Finally, features of the project that affected more than one crucial component of the infrastructure owned by different teams, had to be discussed and analyzed from the Architects team.
Operational teams — To make sure that every operational team understands their clearly defined roles and how the project impacts their daily operations, we have created documentation, visible and transparent to the whole company, scheduled training with key people from every department, making sure that all project updates are communicated to them.
How to track progress
There are many techniques and tools in tracking the progress of a large scale project and surely there isn’t a single one correct approach on this. This is our approach along this project, that may well be altered or adapted for another project.
Teams’ allocation and milestones’ setup — When trying to manage a large scale project in an agile environment, it is essential to involve key people and teams. The aim is to involve teams that own each product affected to ensure business and technical analysis and implementation are sufficient. It is essential to break down the project’s outcome in potentially shippable increments per team and define key milestones. A milestone could be the completion of a feature or part of it. In this stage, Scrum teams have to be involved.
- Product Owners, in prioritizing the backlog based on potentially shippable increments that will have business value.
- Scrum Masters/Delivery Leads, to assist in cross-team dependencies and impediments resolution.
- Development teams, to define technical requirements.
During this stage, teams provide a high level estimation on delivery for each milestone along with all internal and external dependencies that need to be followed up.
Release process — We are following the release train process in our technology division, meaning there are scheduled releases. Our product development process includes code reviewing and thorough testing before something is deployed in production.
As was the case with the milestones, releases were also defined, communicated and coordinated to avoid malfunctions. The delivery manager coordinated these releases among the teams based on their progress for each feature and followed up on them with the teams on a weekly basis. This coordination included the following:
- Defined release dates
- Release notes per release (what is included from each team)
- Operational departments and stakeholders’ training on new features
Risk Mitigation
In every project, risk management is essential for its delivery, as risk mitigation and resolution at an early stage can result in gaining a lot of time ahead. When various teams from different departments are working together for a common goal, issues can emerge for many reasons; technical difficulties, business decisions, compliance restrictions and the way to better manage them is to try to identify them as soon as possible and involve key people for their resolution.
Meetings across departments — Regular follow-up meetings on tasks progress and issues were held with representatives from all departments involved. In the beginning of the project, these meetings were held on a weekly basis, as most of the questions emerged at the start of a project. During them all participants were encouraged to ask questions and stakeholder should take business decisions when needed, based on the needs and restrictions each time. Since many people from different backgrounds participate, it is easier to find workarounds and quick resolutions on risks raised. If a risk could not be resolved on the spot, an owner was assigned to take actions and follow up on it in the next meeting.
Business analysis and technical restrictions — In every project that needs technical implementation, the technical analysis will raise risks that need handling before proceeding with active development. Product Owners whose products were affected by the implementation were involved in an early stage to discuss among themselves product dependencies and consult their teams on technical analysis to define dependencies. As the analysis progresses, an initial delivery plan was created. This plan was updated based on teams’ feedback regularly, to ensure existing risks are managed and new ones are raised and owned.
Project rollout and feedback loops
Complex projects’ solutions may vary according to the needs, the time available or the stakeholders’ preferences, but we need to ensure the solution developed covers the customers’ needs in the most efficient and user friendly way. Creating feedback loops internally and externally makes the whole process more efficient as time is well spent, information is shared and issues are quicker identified and resolved. The following key elements were used to ensure smooth development and release:
Alignment meetings — In our weekly meetings, we discussed customer flows and made decisions on improvements to have an efficient development cycle with minimum back and forths.
Workshops — Gathering people from different backgrounds and analyzing thoroughly the customer flows helped us identify room for improvement or even alter the flows to better serve our customers. During these workshops we made suggestions on how the overall experience can be improved.
Analytics — Setting up key analytics and then adding more, helps define amendments needed in the implementation based on pain points that arise. Stakeholders and Product Owners gather and evaluate this data regularly to define the next steps of the implementation improvements.
Customer feedback — Customer support departments are in constant contact with our customers. It is important upon every related communication or for customer samples to ask for feedback on the feature. Gathering and distributing the feedback to stakeholders and Product Owners leads in increasing the pool of ideas for improvement.
Conclusion
None could argue that there is a single best way to run a complex project, coordinate various teams and bring the desired outcome, so what we tried worked for us but it does not mean it is a panacea for every project .
But we could say that at the heart of our rationale lies Kaizen core value of Continuous Improvement, that is to strongly believe that there is always room for improvement in everything one does.
So, no matter the way you decide to proceed with a complex project we have only one suggestion that works for everyone; retrospect.
Spend some time upon the completion of the project and try to identify the strong and weak points of the process you followed. Try to decide on some corrective actions in terms of processes, communication or involvement throughout the different stages of the project.
And if there is one lesson to be learned, it is that, regardless of the way you decide to proceed, always try to find ways to improve and challenge yourself on the next step.
