The big bang approach may not be the right approach for all companies but with the proper resources, strong project management and good communication it is very achievable and rewarding. As your team works through the project, they will be addressing issues and concerns in a timely manner. Not only will you complete a project, but you’ll have a more cohesive team at the end of it too.
Well, that's the million-dollar question, isn’t it?
We have all used the phrase, but, in my experience, there are few actual million-dollar questions out there. Sure, we can all contemplate if we’re alone in the universe or how many licks it takes to get to the center of a Tootsie Pop, but that doesn’t impact companies’ bottom lines.
Let’s look at something that does: a software implementation. When you add up the number of employees involved, the departments impacted, the training needed for the new workflows, that’s a ton of pressure. How can organizations ensure it’s successful? What do you need to consider beforehand? Do we implement everything at once or should we phase it out?
Zayo Group asked the last question when they implemented OneStream: do we opt for the “big bang” or do we phase it out over time? As the project lead, my role was to help guide them on what would be the best route for their organization and ultimately, they chose to go for it.
Here are some things to consider if you’re wondering if a big bang or a phased approach is right for your organization:
Regardless of the approach, it is critical to have some initial design sessions with stakeholders from each business area in the room. Organizations need to understand what workflows each department currently uses so they can define requirements, configure the proper dimensionality and design the overall application. If you go with the phased approach and do not include all the key stakeholders for all phases in the initial design, then the first phase of the project will drive the design of the application. As a result, the application may not properly be designed for subsequent future phases. With the big bang approach, this does not occur since all the players are involved on day one and all the requirements are being discussed so the proper blueprint of the application can be properly set up.
In any software system, items will overlap and impact other functional areas. Here are two items to beware of as you build out your implementation.
Metadata items.
Departments need to agree on what certain terms mean so there are no discrepancies or misunderstandings between employees. For example, a marketing team and a sales team need to be in agreement on what is considered a lead so they can properly work together on closing a deal.
Stakeholders from all departments should review common structures to reach a consensus between the view or treatment of certain items. Luckily, the big bang approach allows for discussion and early identification of these items. If your company opts for a phased approach, you may not have visibility into these items until one project phase has gone live or into UAT or parallel testing so be sure to have the conversations early.
Application build aspects.
Whenever organizations build any kind of the internal system, the application aspects may impact other functions beyond just the department driving the project. Think about it this way: if you’ve ever completed a house renovation, you know that as you start one project – say updating a kitchen, you have to take other things into consideration (updating the plumbing, electrical, getting the latest appliances, adding an island, etc.). You can’t do one part without taking the full scope of the project into view. You don’t want to finish the kitchen only to realize you should have updated the plumbing.
In the same way, parallel development tasks need to be carefully conducted and communicated. A big bang approach requires close interaction between teams as other teams’ activities can unintentionally override or inhibit other team members’ development activities. In other words, the plumber and the electrician need to be on the same page.
Big projects like software implementations can wreak havoc on your resources. Sometimes, you have colleagues who are stretched too thin; other times, there are employees who don’t need to be on the project at all, but somehow, they get an invite to the meeting. Either way, organizations need to know who is on the project and if those employees have the bandwidth to fully support it.
The good thing about a big bang approach is that companies can keep employees’ overall timeline commitment relatively short. Team members will work together concurrently to make sure the whole project (not just some parts) gets completed by the deadline. During a phased approached, however, teams work must through the project consecutively, meaning they have to start one phase before they begin another. As a result, the phased approach may extend the project commitment for certain resources.
If organizations need certain employees “free” to begin other initiatives, they may want to consider a big bang approach to ensure they’re available.
Hindsight is always twenty-twenty. It’s only when teams are out of the weeds that they can reflect on what they would have done differently if they had the chance. A phased approach capitalizes on learnings from one phase to the next. As employees go through the cycles of the project, they are picking up learnings along the way. They may develop better processes that can not only be rolled out to the next phase of this project but also future implementations. While a big bang approach does not fully leverage the skills development or project learnings along the way, the team would still acquire a skillset throughout the project lifecycle.
Opting for a big bang can seem overwhelming, and yet it can be done. Was the big bang the right choice for Zayo? Yes, and I cannot stress enough the success of the project was because Zayo did their due diligence and looked at these components before it began.
They had dedicated resources for each piece of the project as well as a Project Manager.
They clearly defined the need for each part of the build phase up front and how they would interact
Their teams identified areas where changes to metadata structures and application functionality were desired and were able to address and incorporate these with minimal impacts or risk to the overall project due to being fully in the development stage for both functional areas.
The big bang approach may not be the right approach for all companies but with the proper resources, strong project management and good communication it is very achievable and rewarding. As your team works through the project, they will be addressing issues and concerns in a timely manner. Not only will you complete a project, but you’ll have a more cohesive team at the end of it too.