Sandbox projects are great, but they don't always work. But when it's time to move on, there's still work to be done.
More and more traditional companies are following the lead of Silicon Valley sweethearts like Google, allowing for increased IT experimentation in the workplace. These testing environments, known as sandboxes, offer a unique way to experiment with new technologies and untested code, but also pose serious risks if implemented incorrectly. Because of this, sandbox projects should only be undertaken if the CIO has done enough educating of other key executives in the business so they understand and accept the risks as well as the rewards.
Often times, a project will not produce the desired results, or it will head in a direction it shouldn't. When, you need to know when curtail the effort.
Here are some best practices to follow when it's time to clean up the mess from your sandbox.
1. Have a strategy for project windup once you see the project isn't going to work
This strategy is best served by pulling the plug on the project as quickly as possible. Pulling the plug also means communicating with stakeholders and answering any questions so there is collective consensus to walk away. It is likewise important to let stakeholders know that all is not lost--and that as part of the project windup process, you will be gleaning knowledge from the project that can be invested into future projects.
2. Perform a project post mortem
Why didn't the project work? Getting together with team members and project stakeholders to discuss what went right and what went wrong while the project is still fresh in everyone's minds can yield valuable insights into how to better run the next project, staff the next project team, or revise project goals.
3. Find ways to implement takeaways for business value
It's important not to waste project efforts, even when a project doesn't work. It might be that a great data analytics tool was discovered during the project, or that the project team uncovered a valuable business insight that could be applied in another area of the business.
4. If there is still promise in the project, reinvent it
Sometime projects fail because they were aimed at the wrong business case or the project approach was wrong. In those cases, projects can often be reinvented, re-focused--and become successful.
5. Revisit staffing and management techniques
There are cases where there was nothing wrong with the business case or the project approach, but the chemistry or the composition of the project team just wasn't right. In other cases, the business case and the project team might be right, but project management methodology might be misplaced. (An example of this is a scrum project with rapid prototyping when quality of data and results is paramount and the QA function can't be shortchanged.)
6. Budget/staff reallocation
As part of a project breakdown, both staff and budget should be reallocated to other work as soon as possible.
7. Next sandbox
The key to sandbox work is continuity. Not every project will work, but many will. If you are heading up the sandbox work in your company, it is critical to maintain momentum and morale after a project failure, and to take the positives gained from this work forward into new technology efforts.
- How to avoid misguided metrics (TechRepublic)
- Report: IT's top challenges and priorities for 2016 (TechRepublic)
- Stop asking the CIO for her cloud priorities (TechRepublic)