The Rush, in Retrospect

Preparing for the meeting did not go well. Live, on-site, with client and end customer, and it could have been better.

Crud.

The actual demo was a success, but getting there was not. What happened was not fun. It was not fun for the client, whose expectations were not met. Not fun for our bosses, who dealt with the brunt of the fallout and had reputations on the line. Not fun for the dev team, who worked hard to get the demo even to the state it was in, plus felt the guilt for a less-than-stellar technology rollout.

Now that the smoke has cleared, the yelling and finger-waving has stopped, and blame has been passed around, we can take a look at what happened. Two questions need to be asked:

How did we get here?
How do we keep from happening again?

Getting here was the easy part. Because everything is fine, before it is not! Looking with hindsight, there were a few things that changed silently. Dates got pushed up a few weeks. Demo changed from a tech team demo to a customer meeting. Meeting turned from a demo into a pre-launch. Feature or two changed from the plan. That little technical hurdle that takes longer than planned.

Thinking everything was on track was easy, but as changes to expectations started trickling in from different places, they were not all in sync when the meeting rolled around. And that is how we got here.

The thing is, by then it was too late. There was not time for fallback plan. Strength of will or more management oversight cannot make anything happen faster, or even just fast enough. The yelling was endured, the plan was laid out, the weekend was worked and with a final push, the launch was successful.

Hooray?

The result of a successful launch is good, but getting there smoothly is a better goal. Since this was not smooth, how can we keep it from happening again? Ultimately it falls on us. The client will always be the client, so they may miss art delivery deadlines by weeks, set meetings without our input, and always ask more (for less). Might be annoying at best and infuriating at worst, but clients will be clients!

The point of process is for situations like these, when expectations are key. There were no defined requirements or checklists of what was needed at what date, just that "it should work and be awesome." Somewhere our software process broke down, which led to bad expectations. Running with a broken process is overly misleading too, so by not assessing things early we did not address issues soon enough. At each change in dates, we needed to have been very clear about what features were going to be ready, not a mix of "everything in the contract, just less, with different dates."

The other thing that would help things run smoother is a defined contract style. In broad terms, the types of contracts we have accepted are fixed price and retainer. Quick recap of each:

Fixed Price

• Defined set of features to deliver.
• Defined delivery dates.
• Set price

Retainer

• No specific features, but team is available to work
• Dates are defined for retaining purposes ("start of each month")
• Price is "per time" (hours worked, or monthly)

Fixed price is good when someone knows what they want, and requires a lot more up front planning. People always want fixed price (and want it to be lower!), but often do not take the time to define features. Good for fixed deadlines (trade show demo, bottom-line price for release), and often has some contention toward the end like "that feature was expected" "it obviously should work this way".

Retainer is a good model when people know they need work done, but cannot define what that is, or have a tendency to change their minds, or need to see it to know if it was "right." Usually things are smooth in the start and middle of a contract, and the problems come up at the end of a retainer, where people always question the effort without knowing how long it should have taken in the first place.

Back to the post at hand, we mixed the two. We were signed up for a fixed price with fixed deadlines, then changed the deadlines and were working like a retainer model. Most any change that was requested was started to be incorporated, which was OK until some people were thinking the original deadlines ("no problem, plenty of time!") and others were thinking the (new) demo dates. Now doing retainer-style work was not meeting specific and defined constraints, so while everyone was "busy", it was not focused on the important things.

The contract is now basically concluded, with time to spare! Learning from ourselves this time, we'll likely improve for the next. 

Prototype Rocks Are Better

A common analogy with my bosses is "Bring me a rock." This fictional conversation between an "idea person" and "engineer" would go something like:

Idea Person: "Bring me a rock."
Engineer: "Here is a rock."
IP: "It is not dark enough."
E: "Here is another rock."
IP: "Why is it so jagged?"
E: "You want a darker, smooth-ish rock?"
IP: "Yes, obviously."
E: "Here is a rock."
IP: "...it's too small."

We are not geologists, and this conversation is not really about rocks.

Ideas are not bad. Quite the opposite, they are necessary! People who come up with ideas are vital from an entire organization down to a small development team. New products or features were not written down long ago and rehashed; they were new ideas at some point and through many steps, and sometimes many iterations, became reality!

Ideas are hard to pin down, and sometimes they are fluid. When a person has a great idea, there are steps involved to make that idea real. Many steps. Rambling off a few sentences of the idea and thinking it will be done to any vague expectation of success is hard to achieve. Especially to an engineer who needs (lots of) details.

And yet, this happens all the time. Which is normal in a lot of cases, and idea people and engineers work together to make it happen. It's called "design."

This  situation becomes a problem when the idea person and the engineer are not working together. Suddenly the idea person wonders why their simple idea is not done yet, and the engineer is frustrated at wasting time on undefined "requirements." Two or three iterations of "Bring me a rock" can wear someone out! Compound this with an idea person that changes their idea before the engineer shows them anything, already invalidating some of that engineer's work! Aaaaarrrgh!

That why you need a prototype.

Having a prototype type is the place to really start a conversion with those idea-person-types. It is tangible. It is something to talk to and point at. The dev team needs to get that prototype ready as fast as they are able (keeping in mind their process and maintainability goals), and the "idea people" need to wait until the prototype is ready before making any new suggestions or changes. Unless something is drastically wrong, or some data proves otherwise, stick with the prototype and discuss when it is ready.

Beyond shortening the "bring me a rock" exchange, a prototype clarifies ideas. When five people leave the idea meeting thinking of a rock, more often than not they are picturing five different rocks! Looking together at a prototype may result in a long list of changes, but the changes are defined and everyone is clear on what is being done and what to expect as a result.

Prototypes are also handy when people do not even know the type of rock they want You might explain the rock five different ways, but until someone sees it, it might as well not exist!

E: "It's a round, smooth, gray rock about the size of a grapefruit."
IP: "I've never seen that before."
E: "I haven't built it yet. Just try to imagine it."
IP: <blank stare/>

Great explanations and ideas will only go so far. At some point it needs to be tangible. And once it is tangible, people can actually engage in the conversation.

Hopefully bringing rocks and asking for rocks will be part of you future. Just remember that prototype type rocks are better. For everyone.