[This is part of a series of posts describing how IT contracting compares and contrasts with the structure described in the PMBOK.]
Powerful economic and technological forces have pushed IT resource consumption to the “as-a-Service” model, commonly referred to as “cloud.” This is where Platform-as-a-Service (PaaS,) Infrastructure-as-a-Service (IaaS,) Storage-as-aService (STaaS,) Software-as-a-Service (SaaS,) and all the other “aaS” acronyms arise. These are essentially provided via unit pricing, in what is popularly called “pay by the drink.” This afternoon, you can spin up an entire IT infrastructure using only a credit card and a good IT architect. You will be charged incrementally for the number of sites, servers, network ports, storage increments, data units transferred, and/or transactions provided this month, this week, this day, and even this hour.
From the PMBOK perspective, this is the ultimate in unit pricing. This can be challenging for the project manager procuring these kinds of services. The unit prices are perfectly visible and reasonably predictable. However, the actual project costs may be complicated to manage over a long enough horizon as the consumption of specific service units may be hard to accurately predict or to control.
When I spent some time working with a supplier of Stuff as a Service, we built complex custom spreadsheets to create the unit pricing model for specific customers (especially for the support services.) As a consumer of these service, you may need to create a similarly sophisticated model to show the likely long-term costs for consuming these services in different operational scenarios or business outcome scenarios.
The services available in this cloud model cover a kind of “vertical spectrum.” At the lower levels of the spectrum, where you are subscribing to infrastructure services, you are essentially renting hardware and renting the space in which it sits. It should be easy to see that Infrastructure-as-a-Service still requires some kinds of infrastructure support. (What happens when there is a product hiccup of some kind, and who will deal with that problem?) At the higher levels of the spectrum, you are subscribing to capabilities where certain kinds of support are included and invisible. Nevertheless, using these kinds of services frequently still requires some kind of ongoing support. The higher the level of the subscription, the higher the level of auxiliary support required. The subscribing organization may choose to provide that support itself. This may be part of the organization’s core competency and competitive strength. Alternatively, the organization may choose to subscribe to a supporting service to support the first service.
As an example, consider renting a car. When the consumer rents a car, the automotive maintenance is included in the service. The driver hopes to never see the specifics of how that service is delivered. On the other hand, do Hertz and Avis each do their own vehicle maintenance using their own staff? Do Hertz and Avis find that they have a competitive advantage in how they manage fleet maintenance? Or do they contract vehicle maintenance service out to a supporting business? (I am sure that all the rental companies study the finances of these questions almost continuously.) I will cover how these kinds of IT support services are procured in a separate post.
[I welcome your comments and feedback based on your experience managing cloud transformation project or procuring these kinds of facilities. Feel free to contact me directly.]
(Image courtesy stevepb at Pixabay.)