As much as we’d all like to work in an organisation where resources are unlimited, time is unimportant, and our competitors move slowly (allowing us ample time to respond), the reality is often vastly different. In many industries, new technologies are allowing nimble start-ups to enter the market with different and sometimes disruptive business models. New channels mean that our competitors can reach clients in new ways—and our clients can interact with each other faster and with more transparency than ever before. Markets move and develop with increasing momentum. Just ten years ago, letting a smartphone ‘suggest’ a local hotel and taxi firm would have seemed insane. Today, it’s possible to book an entire journey with a smartphone, figure out which of your connections are nearby, book dinner and see what’s on at the local cinema all before you’ve boarded your flight…
In this constantly changing environment, utilising external environmental analysis techniques like PESTLE or STEEPLE becomes crucially important. Smart organisations will continue to regularly adapt, experiment and implement change with increasing speed. These changes can be small (perhaps a new incremental change to an existing website) or massive (cannibalising an existing product in favour of launching something completely new). These changes can affect any part of the business eco-system—the IT systems, processes, organisational structure, facilities, plant/machinery, products or proposition and so on. And increasingly this will involve liaising with skilled partners—internal or external—to help build, customise or buy elements of the final solution. It may involve procuring IT from selected vendors or services from managed service providers (MSPs), as well as engaging a wide range of internal stakeholders. It may even involve outsourcing or insourcing a capability.
In this race to get change implemented, so often, constraints get forgotten about. Or rather, with the fire behind us and with a strong sense of urgency, it is easy to delay a discussion about what will constrain us. Yet as alluded to in my opening paragraph, it is highly likely that we don’t work in an organisation where time, budget and resources are unlimited.
Leaving our constraints un-discussed and un-stated is akin to locking them in a dark, dank cupboard and just hoping they won’t affect us. We become like ostriches, with our heads firmly in the sand. Even worse, different stakeholders have different views over which constraint should be compromised. It is worth considering the traditional triple constraint of project management here. The Sponsor may hold budget as the most important unbendable constraint. The customer service team may feel that quality can’t be compromised on, with the marketing team advocating time as the most crucial factor. This is before we even discuss the rocky issue of scope as well as any other business or technical constraints.
Bringing constraints out into the daylight
It is important to bring these constraints out into the open. A very talented project manager I once worked with had a printed sign above their desk. Good, Cheap, Quick: Choose any one. I’m sure we’ve all seen various versions of this sign, which is often meant (at least partly) humorously. All jokes aside, it acts as a useful reminder for us to have these crucial up-front discussions. Before a project is launched it is important to have an open and honest conversation about what are the real constraints. What really can’t bend? And what can we compromise on.
In order to understand this, we also gain a deeper and richer understanding of why the project or initiative is required in the first place. If the aim is to be first to market then time is crucial. But if time can’t bend, what else can bend? Here are just a few possibilities:
Time fixed, scope can vary: We’ll get as much as we can done in the time, and providing we get a minimum viable product (MVP) we’ll launch it. In fact, we may deliberately choose to launch early to test whether there is demand.
Scope fixed, quality fixed, time can vary: We need a high quality product. Perhaps we’re a communications company launching an innovative new type of satellite into space. There’s no point launching part of a satellite—we’re unlikely to be able to ‘incrementally’ add to it after it’s launched. And there’s virtually no opportunity to fix it once it’s in orbit, so quality is paramount. We’d rather wait for a quality product than launch a piece of space-junk.
Budget fixed: If there really is only so much money available, then what are we going to do if there are unexpected complexity costs? Do we reduce scope? Do we compromise quality? A real danger lays waiting for us when scope is guarded so fiercely without consideration of what else will bend. With nobody wanting to let any features drop, there is a risk that an end-deliverable is shipped to a user-base that does everything it set out to do (but does it unreliably as the quality had to drop). Open and honest conversations, early in the project lifecycle help to make these later difficult and emotionally charged decisions easier.
These are just three examples. Of course, there will be other constraints too. Perhaps there are technical constraints: We may need to implement particular types of technology, or we may need to interface with existing systems. There may be business constraints: perhaps certain organisational boundaries cannot be changed, or certain internal cultural issues need to be considered. These are equally important and are worth highlighting early.
In summary: Openly discussing constraints before a project is launched and continuing to review and discuss them throughout, can help ensure that all stakeholders—including delivery partners, vendors and MSPs, are all aligned on what is important. It will ensure that we deliver the business outcomes that our stakeholders and sponsors need.
What are your experiences and tips? I’d love to hear from you. Please add a comment below.
If you’ve enjoyed this article don’t forget to subscribe.
This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business
