We’ve all been there. Walking down the street, in the distance you see your bus pulling away from the bus stop. Frustrating, but not the end of the world. After all there will be another one coming any time now… won’t there?
In the software development world however, “missing the bus” can be more than just frustrating, it can be very costly.
What is My Schedule?
In a more traditional Waterfall project methodology, all phases of the project lifecycle for a particular project are based on a carefully assembled project plan. The number of team members and the amount of effort for each task within a project determines the end date and therefore the scheduled deployment date.
On the other end of the spectrum are the projects that follow an Agile methodology which commonly have a two week sprint cycle. These projects are broken down into small enough components so they can be deployed in shorter timeframes.
The relatively new idea of a bimodal IT structure may have aspects of both Agile and Waterfall delivery schedules. The intersection of the two worlds poses unique challenges. The practical implementation of a bimodal strategy and how to successfully manage seemingly disparate methodologies would be a topic for a different discussion.
A very common occurrence is to have predetermined system deployment dates. This approach is more agile in nature, but rather than a 2 week sprint, the deployments may be monthly, bi-monthly, or quarterly for example. It is this predetermined schedule that I refer to as my “bus schedule”. This predetermined schedule is often set up by a PMO group on a year to year basis. It is no coincidence that companies that have a predetermined schedule are the same companies that utilize a hybrid approach to their software development lifecycle. This hybrid approach is neither completely Waterfall nor Agile but takes pieces of each methodology. These pieces can be different from company to company.
I Missed It - What Did it Cost Us?
To be sure, missing a deployment deadline in either a Waterfall or Agile project can be costly. Fortunately, the controlled nature of Waterfall and the flexible iterative nature of Agile help to minimize the costs - how exactly would be part of a different discussion.
Costs for missing a deployment, regardless of why it was missed or the project methodology used can include:
- Opportunity costs from not having the new application; new features or functionality; or losing out on cost savings when implementing improvements or strategic decommissioning.
- Resources costs, whether it is due to project rework or the opportunity cost of the resources not working on new endeavors.
- Depending on the nature of the project and the length of delay, the organization may also be dealing with penalties associated with government or industry regulations, client dissatisfaction, or in extreme cases, loss of business.
- Often there is a hidden cost of employee satisfaction, and ultimately employee retention.
Staying on Schedule
In the past 20 years, I have been in many different organizations. Some of these organizations have had predetermined release schedules where project teams repeatedly missed the scheduled deployments. I believe this may have been for any number of reasons - because tasks took longer than expected, unforeseen issues, or changes in scope. Sometimes projects never even got out of the backlog. The projects a team planned to accomplish for the next deployment got pushed further back into the project backlog, leaving them with nothing significant for the upcoming release.
So just how does an organization and project teams stay on track and consistently keep to the schedule?
To begin with, there is simply no substitute for having highly skilled people doing the job you are asking of them. As we all know, successful tracking of projects depend on accurate estimates, early identification of risks, complete and detailed requirements. This extends from project managers and business analysts to developers, testers, and support personnel.
Assuming an organization has the people and skills needed, what else can be done? Although every organization is unique and every situation different, there are certain strategies that could be applied to “catch the bus”.
- Add more “buses” to the schedule - Often the fewer the deployments the larger they can be, involving many new and changed applications in one release. This has the effect of being a “big bang” approach. Having more frequent deployments in the release schedule will allow more opportunities for teams to be successful. More frequent releases will reduce size of each. As a result, the time and effort of each deployment are also reduced. Obviously for this to be true, program management discipline must be applied to make sure each scheduled release doesn’t get too large with projects.
- Who / What / Where / When - Make sure the right people with the necessary skills are in the right place at the right time. While it is not always possible to have each team fully staffed, it is very important that people are available when they are needed. This will require project teams to cooperate and share certain high demand resources. This will also require a high level of cross-training. For example, individuals having wider range of knowledge within current role (e.g. QA Tester trained on testing a wider range of business systems) or individuals applying current knowledge to wider range of teams / roles (e.g. Business Analyst using system knowledge to write not only use cases, but also test cases).
- Resource Optimization – Some companies provide each project team with dedicated resources, making sure that the necessary project management business analysis, development, and testing resources are assigned. While each individual project has exactly what they need to be successful, there are times when resources are underutilized. This may also lead to redundancy, having similar resources in different teams performing the same work (e.g. having the same application functionality going through regression testing by two different project teams.).
- Leverage capabilities of tools – Many third-party software packages have built in tools that allow for more flexible processes that can be leveraged to make the release cycle more efficient. These may include tools for automated testing or revision control; or unique processes for reviewing and “publishing” changes to production. Rather than “shoehorn” these packages into existing deployment processes for the sake of consistency, be open to using the software’s full capabilities and having unique processes where it makes sense. You may find that not only do deployments go smoother, but you gain more value from the packages that you’ve purchased.
As we’ve all experienced, when software development projects miss prescheduled deployment dates it can be very costly. By looking at the problem from a unique perspective, we see that there are many different strategies an organization can implement that allow each project team to achieve success. Whether the best solution for your organization is resource, process, or technology based, having an experienced partner to help the organization through change is invaluable and often overlooked. The key is to find a partner with not just business acumen or filled with technology zealots. It is vital to work with a partner that is experienced in blending both process and technology solutions to achieve success.