In 30 plus years of delivering solutions to clients of various sizes, one dichotomy continues to perplex - 'conventional IT governance' versus 'cloud-enabled updates'.
A simplified view of conventional IT governance procedure for desired changes to a system is:
- A User identifies a system need and logs it for the System User Group (SUG) to review;
- SUG community builds a list and prioritizes system needs for submitting to IT;
- Requirements are presented to the System Steering Team (IT SST) - that is comprised of IT or consultants as IT Surrogates;
- Vendor Requirements are developed by the IT SST;
- Vendor completes design, development, testing and deployment tasks in collaboration with the IT SST.
- SUG Team performs user acceptance testing
- Users get to use the system.
This sounds simple and intuitive enough and it passes the logic test of being, and sounding, commonsense.
Much of corporate, agency and institutional IT process embrace this procedure.
So, what's the downside? Well, there are a few. Each of the items in the quality triangle: Time, Cost, Quality (Fast, Cheap, Good) are adversely impacted in this arrangement.
A short discussion of these impacts and a proposed alternate approach follows.
Time, Cost and Quality Impacts of the Conventional Governance Approach
Consider the user experience. Users discover a systemic issue. They are told to place it on a list and prioritize it. The System User Group (SUG) will review and decide whether it's worth escalating over other, already identified issues. Escalated items are passed along to the IT SST, who then spend a few weeks creating appropriate requirements documents. These are reviewed with the SUG to ensure accuracy and completeness. More weeks pass. The Vendor has its list of items and goes to work based on the service level agreement (SLA). In a best-case scenario, the design, development, testing takes a few more weeks. Before the changes are available to the users. A few months have elapsed. Users have developed and operated with Plan B, while the improvements we being created. Time is not on their side. The improvements may now fall short of the results that they are now obtaining with Plan B. The requirements have changed, due to improved and increased awareness of the users. This request to completion process is too long and cumbersome to keep up with the user's real-world needs and so a spreadsheet solution is employed for Plan B. This further erodes the system's value. Quality is diminished. IT SST is now presiding over a degraded system, while their costs remain elevated to maintain the procedure for other requirements. Costs are excessive.
All three sides of the quality triangle come up short - this is not good!
Cloud-enabled Service Delivery
TeamWork Group is evolving an alternate, user-driven approach. Our TeamWork Integrated Solutions Technology (TWIST) service is available on line.
Users record their requests on line. The vendor, TeamWork Group, is immediately aware of a potential shortcoming or feature request, etc. and with our central role in the TWIST cloud, can determine whether that issue is resolvable and can be a part of a solution pack that is already underway. Time is less. The economies that this approach affords are huge! Cost is lower. As the - as the system is available online and in the cloud, the deployment to a test environment can be done in hours or days and the production environment can get updated in less than a week. The chances that the user has moved-on to other approaches is lower. Quality for the user is high. This approach is currently employed by all app builders as well as by Microsoft when deploying new versions of the Windows OS, so it is not really unique to TeamWork Group.
What are you waiting for? Time to head out of the woods! We'll make it easy for you.