Bridging the gap between programmers and the vision

A successful project will have a hard time flying if you don't walk through the game plan before writing a line of code.

A successful project will have a hard time flying if you don't walk through the game plan before writing a line of code.

Having worked in the media industry for a while now I've often heard grand plans based on fantastically clichéd adjectives mixed with vague ideas and plans. It's an easy area to pick on but I'm sure there are other industries with similar problems.

If you've ever sat down to talk about a project and you hear words like "world class", "leading edge", "best-of-the-best", "Top Gun" and so on to describe a project's vision then you'll know what I mean. Big plans often come with little substance for programmers and technical people.

So, as a project manager or developer, how do you cut through the BS and work out what the client really wants so you can resource, budget, estimate a timeframe and measure success for the project?

The trick is to get your client, boss, or colleague to define the project in the most clear and concise way. Don't even attempt to write a line of code until this is done. As Vanilla Ice once said "All right stop. Collaborate and listen."

Your approach should vary according to different types of clients and the way they work, but essentially it will be up to you to decide the best way to engage with the client.

One of the best ways to engage clients, especially non-technical clients, is with storyboards and pictures. If the client can visualise, or help you visualise, what needs to be built then you're starting to talk the same language. Story boarding with clients can get them engaged on the specifics of how they see their idea working. It's also a good chance for you to offer your feedback.

Another way to get a crisp and clearer idea of your clients vision is to ask your client what other similar products or services are on the market, ask your client what they like and dislike about those products and describe why their idea is different and better.

Ask your client to describe the software system's users. Who are they, what do they do, how will they engage with the software? This will gather a better understanding of what you'll need to build and the types of UI to build and who to start testing the product with.

Get the client to describe the core function of their plan. Don't let them deviate from what this core function is and get them to describe this core function in detail. Get them to keep it simple.

After hearing your client's game plan you'll need to write out a spec and maybe create a small demo or prototype. Depending on what type of company you are, this will vary, but the idea is the same -- it's a measurement of what to do and how to gauge a project's success.

Your client's grand ideas are only as good as how well they can be transferred into code.

Bridging the gap and setting out your clients expectations, goals, and success from the get go will go a long way in getting the project up faster and running successfully.