How to keep momentum moving in the absence of critical requirements?

Question

I have a less-than-ideal situation; A project with extremely tight timing and an engineering team expected to develop against a moving target. We have a research/user experience team delivering draft storyboards and conducting design assessments. Our mobile team is developing against the storyboards and reviews, but our web engineer has not yet been on-boarded so there is a gap in requirements - the API definitions don't exist, and they're likely to change as the user experience is fine tuned. The web engineer will be local and the mobile team is remote.

Since the majority of the computational workload is going to reside on the server and rely on the API, what can I communicate to the mobile team to keep momentum as storyboards are finished and data/server models need to be developed?

My current plan is to work with another web engineer and provide a draft API outline for the "easy" models first, such as CRUD for a user model - but I'm not sure if that's ideal

Answer 1

It's a matter of risk management. Clearly you can start the dependent work early, but doing so incurs risk on the project- How much risk is determined by the a number of factors but two key factors are:

• The approach you take to defining the interface up front in the absence of the right resources and clear requirements
• What is the impact of getting it wrong?

You could use a similarly qualified resource and make a best-guess (which appears to be your best bet) or you could derive a notional interface from the consumer end, or probably many other approaches. Some are likely to be more accurate than others. By accurate I mean, more likely to be close to the design that would be done by the right person and therefore likely to incur less re-work. You need to take advice from as many of the right kind of people as possible, to try and find the path that is most likely to yield the most accurate interface.

Then, having picked one or two of the most likely, you need to work out how wrong they might be (very subjective, find people experienced in this kind of interface and system) and work out what the cost is to the project of various degrees of wrongness, from "a total rewrite" to "tweak a few function calls". This will give you a range of possible consequences in terms of additional timescale and effort.

Once you have the consequences as well thought out as possible, you need to raise the appropriate Risk in the Risk Log and immediately escalate it to the Project Board (or other appropriate power). Include an option which is to delay the technical items until you have the right upstream resources in place, in other words, doing the right thing, and ensure you have worked out the timescales and costs for that.

Then let the stakeholders determine which course of action they prefer, raise a change on the project to incorporate the appropriate budget and timescale changes, and off you go.

You might find that one of the apparently sub-optimal options is actually the cheapest. Or hopefully your analysis will show that you need to be allowed to do the right thing. But whatever the outcome, ensure it the Project Board or equivalent, that has chosen the path as that protects you and your project.