Project PitBull: Crisis

The reason I code named this project "pitbull" is I knew with such aggressive deadline and scope there was a high probability this project could bite ones face off!
And so I think it has come to pass. We are in crisis mode because the apis are waaay behind from where they should be.
Some time back, I told the PM and API lead all apis needed to be complete no later than 2 weeks before launch, it's 2 weeks before launch today and the apis are basically started, I'd say approx 30% or less complete.
Unfortunately I could see this happening and raised the problem with a number of people but assurances of delivery and progress won the day, until now. And when I rose the issue, I was not aware of the true scale of data the client had to provide or lack of build progress.
Today I created a spreadsheet which lists all the apis, true detailed status, responsible parties etc. It has indicators for each step in the process from data from client to api successfully integrated on frontend. Its status on one page which we needed a month ago and finally provides us a true status of how things are. In a word: bad.
I think we have to cut scope to make launch. Right now I fear we run the risk of missed launch.

In my experience data feeds and cms entry are major risks to schedules. When depending on the client there are too many things which can go wrong: they start too late, misunderstandings between teams, staffing issues and so on. All result in deliverables being missed. And missing deliverables have knock on effects since there's a whole dependency chain. So thats a lesson learned and here's some best practices.
But I honestly think client data delivery issues are the smaller problem here. The bigger problem is the apis are not built.

What needs to be done when receiving data from client:

1. Set a clear schedule of deliverable dates with the client which allows time to validate, load and build the api. Be clear on implications of missed deliverables
2. Quality check down to field and value level each data drop. If no correct then reject.
3. Agree a rejection turnaround time e.g. 1 day
4. If drop is still bad, escalate and slip dates if deliverable is missed

What needs to be done when managing:

1. Be paranoid, assume the data will be bad, assume misunderstandings, assume more time than expected. You need to be on top of risks and dangers to the project. The best managers are on the ball, on time, on agenda, efficient, have good domain knowledge and are always assessing both the big and small picture (almost as second nature); they can sense issues in their infancy and address them. 
2. Don't trust developer promises, assurances or estimates until the trust is earned with on time delivery. Even then its best to expect the worst, definitely do not go with the optimistic estimate. Make facts the most important data point, less so what people say or promise 
3. If dates are missed then do your job and get on peoples case, understand causes, consider fixes and options and implications, escalate if need be...but whatever you do, don't do nothing. 
4. Put someone in charge of data who gets the data, is passionate about it and understands it or is quick learner but who also has high standards for quality as well as a clear mandate for managing and escalating.

I've been lucky to work with two great PMs at Fluid, they embody these traits and more.

Developers:

1. Be honest with yourself. 
2. Know when you're in over your head and when to ask for help. Know the warning signs e.g. If you're missing your own dates then something is wrong and action must be taken. If you're getting more scrutiny in status meetings. If you still have little working.
3. Listen and talk to other devs. Many of us with experience have been through the grinder but are generally too busy with out own work to help you unless you ask. If you say you got it under control then ok, I trust you do (so please see #1 above).
4. Have a plan, an approach, rules etc. on how apis will work and be consistent. Ideally mock up one or more sample responses at the start which you share. You should define the api, don't lets others do that or it'll just be a mismash.
5. You'll probably need to do estimates. This is a big topic but I think the 2 most important things are: a) know what you need to build. Sounds duh but it often happen people miss major requirements. For apis you need to at least have a complete list of what you need to build. and b) have a good idea of your design on how to implement. Armed with those 2 data points you can at least create an initial estimate with some basis of fact. Then consider time for environments setup, supporting api users, meetings, troubleshooting data, api usage etc. This could will take 20% of your time over a project. Be conservative.

Ok, its 1:21am, I could not sleep without this literary therapy but I think I feel better for putting it down. I'm a developer, but I have worked in a number of roles including project manager and I've had experience with many projects large and small.

Next post is back to technology items and hopfully crisis averted.