Image: Boris Jovanovic, Getty Images/iStockPhoto

In a typical IT project, scope is the main driver of the outcome. The project is tasked with accomplishing a particular goal with a relatively fixed budget, and therefore the time it takes to accomplish that goal tends to become a bit fungible. Even before the team is assembled and work begins, most IT leaders will design their projects based on a “reach” deadline, and then a more realistic deadline that’s whispered in planning meetings with a wink and a nudge when it looks like the reach goal is unlikely to be met.

SEE: TechRepublic Premium editorial calendar: IT policies, checklists, toolkits, and research for download (TechRepublic Premium)

This mode of operating generally doesn’t fool anyone on the project team, or the beneficiaries of the project, who generally start work with the expectation that dates will slip as needed, and that checking as many boxes next to key elements of scope is more important than unfailingly hitting a date that’s assumed to have been developed in a rather arbitrary manner from the outset. Even with agile-based approaches to project execution, there’s always the possibility of adding another sprint or two, or tacking a modified mini-sprint on the end of the timeline to get that one last feature across the finish line.

While this approach may very well be relevant for key systems that simply won’t work to their full potential without a minimal set of features, it can be the death knell for more experimental or strategic projects where the outcome and feature set are less certain. If your organization is like many that have tried to apply a scope-focus to these types of projects, you’ve likely found that your project begins with a great deal of gusto, then the scope quickly expands or refocuses, and after a month or two the effort fizzles out without accomplishing much of anything as all the work has been spent on defining and managing scope versus accomplishing a meaningful outcome.

SEE: Tech Budgets 2021: A CXO’s Guide (ZDNet/TechRepublic special feature) | Download the free PDF version (TechRepublic)

Box the time and money, and scope will follow

Contrast the typical IT project approach with the typical product launch, where a date is essentially set in stone, and features and functions are adjusted or even dropped in order to make the date. I’ve extolled the virtues of a product mindset in the past, and this approach can be even more effective for a short-duration experiment that either tests an unproven technical capability, or provides clarity and direction to a strategy project.

By their very nature, these types of projects don’t have an easily definable scope and will require flexibility and creativity, elements that are not only unusual in typical project environments, but ones that are actively suppressed by management structures like stakeholder committees and change request processes.

If you have a strategic or technical problem that’s been repeatedly deferred, or moving along at a frustratingly slow simmer, launch a 90-day experiment meant to either justify a larger effort, or shelve the idea for the foreseeable future. Your scope is simple: At the end of 90 days you should have a decision on whether to abandon the strategy or technology, invest significantly in building it out, or launch another 90-day experiment with a specific objective; in short: Kill, scale, or another experiment are the three potential outcomes.

SEE: COVID-19 workplace policy (TechRepublic Premium)

Empower the team to decide the rest within any budgetary or other loose constraints, but ensure that everyone is clear that the duration of the effort is absolutely fixed at 90 days. With a reasonably motivated and creative team that’s supported by your leadership, you’ll be surprised how typical organizational roadblocks are suddenly avoided and frequent debate and scoping sessions are suddenly abandoned. Just like the product team firing on all cylinders to make their launch date, your team will quickly focus on what’s important, and abandon what’s superfluous in their effort to justify whether the program should be killed, scaled, or funded for another 90-day cycle.

There’s little magic to 90 days, beyond the fact that it conveniently occupies a calendar quarter and is long enough for meaningful progress, yet short enough to avoid succumbing to the organizational quicksand of meetings and consensus building that plague most experimental efforts. Ninety days is just short enough to instill the urgency and low-grade panic that drive creativity and rapid decision making, and as I write this, is also a convenient time frame in which to make meaningful progress on a difficult strategic objective before the calendar year draws to a close.

After running a 90-day experiment or two, you may find some team members naturally drawn to this style of work, ultimately providing a capability for your organization to rapidly advance difficult strategic objectives on a rapid basis, a capability that will quickly become an asset to your organization as a whole.