Bad beginnings have bad endings

“Mali principii malus finis.”

– Proverb

I like quoting Latin proverbs because it makes me feel smart. It also makes me feel like I am not alone since someone wrote about my situation 2,000 years ago!  Feeling smart and not feeling lonely, however, doesn’t help in getting off to a good start on a project.

There are some situations that, when traced back to their root cause, reveal that they went wrong right from the beginning. If you leave your house and turn left instead of right, you are going to have to reverse course entirely to get where you want to go. (Technically, you could make two rights and another left and be back at home ready to take another left to go right, but you get my point.)  The longer it takes you to figure out you are heading the wrong direction, the longer it will take you to get back on the right path, but at least the right path is still open to you.

If you get on the wrong airplane, however, you have no opportunity to turn around until you complete a leg of your journey to the wrong location. It doesn’t matter when you figure it out, once the door is closed, you are not able to reverse your course for a period of time. In this case, there may be no way to get where you were supposed to be (on time) since there may be no way to get where you are going directly from where you ended up.

Technology work is more and more like the second case of the wrong airplane. In the old days – you know, 5 or 10 years ago – if you were developing your own systems, you could make the equivalent of a wrong left-hand turn by selecting the wrong hardware or the wrong hosting company or the wrong widget, and you could start your recovery as soon as you figured that out. These days, however, with so much software as a service, it is usually not until implementation is done, or until you are in operation, that you figure out that you got on the equivalent of the wrong plane.

Great, you may say, but what should you do to make sure you don’t have a bad beginning?  A few things:

Get your users involved early

Get the people who are going to be using the system day-in and day-out involved. Whether you do this representatively through super users or by going directly to typical users, having them engaged in a demo and then in a trial is critical. You will notice I didn’t say your users’ management. Management, of which you may well be a part, is good at talking about “what” they want, but it is the day-to-day users who are going to be best positioned to work with you on the “how’s.”  If the users and the system are at odds, trust your users at this point and spend some more time up-front on design.

Do proofs of concept to confirm key expectations. Prototype what you can prototype

You may need to do some of this work before you can engage your users in using the system or you may be able to start with a “vanilla” configuration. The purpose of getting proofs of concepts or prototypes is to make sure that you made the right first turn or that you are at least in the boarding area for the right flight. If all you can do is a paper-based walkthrough in a conference room, at least you can prove the data flow is correct and that the system is likely to have the data it needs to do what it is supposed to do.

Plan to fail fast if you are going to fail

Don’t plan to fail, that is silly. But IF you are going to fail, do it quickly. This means that you are going to use those proofs of concepts, prototypes, and end-user interactions to demonstrate the correctness of your project’s key underlying assumptions. Are half your users going to be working remotely?  Test out remote access early. Do you need to continue to have users on the system while it is being backed up?  Test that. Does the system need to fail over if there is an outage?  Kick the plug out of the wall before you go live. Don’t wait to find out that all the little things work, but that the big ones don’t.

Keep your users bought in

It has been said that a good politician is one who once bought, stays bought. A good user is one who once bought-in, stays bought-in. That ongoing buy-in is up to you. After the initial interactions, keep your users involved. Add a key user to your development sprint reviews. Buy a box of donuts and have the users come in a little early for breakfast and a demo. Ask the users to work with you on the finalization of the user training materials. Do whatever you need to do to keep the users believing it is their system that they get to use and not your system that they have to use.

If you don’t know enough to board an airplane, take a bus so you can get off at an earlier stop

(I’ll stretch my analogy just this last time.)  Maybe you read the above and feel that you don’t know enough to commit to a path. For example, you are not sure it is possible to do what you want, or you don’t know if you’ll have commitment for all the phases of a project. Then instead of committing to flight with no good way to stop in the middle, consider taking a bus. Lay out the project into discrete stops and decide at each stop whether you have gone far enough or whether you can go one more stop. This is essentially the difference between agile development and deployment and a big bang delivery model. Make the less risky choice, and if you sacrifice some speed for flexibility, at least you won’t end up in Philadelphia (PHL) instead of Phoenix (PHX) by making the mistake of one letter.

One more proverb, in English this time: All’s well that ends well!