From Idea to Specification and Prototype

In this article we give examples of the pitfalls that can trap the most ambitious and experienced entrepreneurs, and share our best tips for succeeding in their IT efforts, both from our clients' and our own perspectives and expertise.

“Castles in the Air” or a Genuine “Rainmaker”?

“Here are the plans for my dream home. Throw something together and we’ll talk when the deadline arrives,” said no client to any building contractor ever. And yet, that’s exactly the attitude many people have when it comes to building their “dream” IT solution. It all began with a vision (or, just as likely, with a problem that should have been fixed five years ago) and now the time has arrived for the “Grand IT Project” that will turn vision into reality. Grandiose plans are exciting, we admit, but in our experience, a lot can go wrong along the way…

According to Project Management Institute’s annual survey conducted in 2018, more than 50 per cent of all projects don’t go according to plan and around 15 per cent are considered outright failures. What’s more, regardless of whether a project is considered successful or not, on average, around ten per cent of its total budget will be wasted on non-essential expenses.[1] Unfortunately, figures like these are hardly encouraging when you’re staring down the barrel of a major IT project.

Not only that, the dynamic IT industry is characterised by plenty of uncertain variables that can alter the preconditions for success overnight. That said, we should be careful not to buy into the idea that we’re forever at the mercy of chance. While it’s true that things don’t always go as planned and that fate can sometimes throw a spanner in the works for even the most experienced project manager, the difference between a successful project and a failure lies in factoring “chance” into the equation. In doing so, you strip it of its power to outmanoeuvre you.

Strikersoft CEO Fredrik Wångberg has been involved in development projects since the early ‘90s. Right from the start, he’s observed that people are willing to take major risks when it comes to this type of project: they have an idea that they want to put in motion right away, so they skip the groundwork, which only guarantees that they end up with a more expensive and riskier project in the long run. “It’s a little bit like scrawling the plans for a million-dollar home on a serviette, giving it to a builder and asking them to start building, saying: ‘You’re an expert. You’ll figure it out’. No one would ever do such a thing,” says Fredrik.

On the other hand, when it comes to IT projects, people are more than willing to take shortcuts and expect that their idea will become a reality just as long as someone with enough skill sits down and hammers out some code for them. They view investing in feasibility studies, mock-ups and prototypes as being too expensive.

“This approach often leads to disappointment, a blown budget and late delivery,” Fredrik explains.

Still, it’s not all doom and gloom. There are some useful guidelines that can reduce the risk of failure and help avoid potential budget disasters before things get out of control. We take a look at what you should do here below:

Step one – take a step back

It’s easy to let impatience get the upper hand when starting a project. You can see your vision so clearly; an elegant solution that works like a charm. All you have to do is to make it a reality – and as quickly as possible at that. But when a truly brilliant, crystal-clear idea presents itself, don’t rush in head-long. In fact, the wise thing to do is to take a step back. Ask yourself: How well-defined is your vision, really? Can you distil it down into concrete requirements and user stories: Who will use the product, how and for what purpose?

When building a house, simply having a blueprint showing walls, a roof, windows and a door or two isn’t enough. You need detailed plans and definite requirements specifications, building permits and soil analyses. Where will the house be built? What kind of foundation will you lay? What other factors should you take into consideration? Is that rocky ledge 112 metres above the sea really the ideal place for a row of terrace houses built for families with small children, for example?

Likewise, an IT project must take into consideration more than just the structure and building process themselves. External factors that could affect the outcome in both the short and long term, both within your own organisation and in relation to third parties, must also be included in the planning. It makes no difference how attractive a house is if it falls into the sea because you laid its foundation on swampland. Or perhaps failed to lay any foundation at all. Or if it turns out that there’s no room on the plot to extend the patio as you had planned.

Bogdan Shelest, Strikersoft’s Head of R&D, believes that the first thing you should investigate when making contact with a new client is just how far along in this process they’ve come. He also emphasises the importance of identifying risks early on in order to minimise them:

“Before getting started, we need to find out what the client’s aims are and what they expect from us and from the project. We also need to determine whether or not they’re ready to start, or if we need to go back to the drawing board and specify their idea more clearly.”

One example of an obvious risk factor is unclear or unrealistic specifications, such as wanting to build a new product on an ancient platform. Bogdan explains that Strikersoft is sometimes forced to turn down clients who have too unrealistic a view of what’s required for their project:

“We always inform our clients if their projects are either unrealistic or impossible to carry out. At the same time, we make sure to suggest alternatives and to try to find a way to solve their problem anyway. They can then either go back and do the homework themselves and get back to us, or we can help them design more realistic goals. Regardless of the outcome, they’re often very grateful that we’re open and honest about their project.”

Plot your course step by step…

Once you know where you are and where you’re going, it’s time to decide just how to get there. So, what’s Step 1? What are your limitations in terms of time, money, resources and expertise? Do you have all the expertise you need?

It’s not simply a matter of setting a deadline or two, nor of drafting a plan covering everything that needs to be done until you reach your goal. In fact, that’s a sure-fire way to blow your budget. Instead, you need to identify what’s required to generate some benefit from your new product as soon as possible.

One common trap that is oh-so-easy to fall into is the desire to guarantee a deadline by which time everything will be finished. Just setting a date is not in itself some kind of magic formula for ensuring that everything will automatically be ready to go on a particular day. The problem is that it’s impossible to predict at a project’s outset just what the “everything” that needs to be completed includes

Sara Bern, Key Account Manager at Strikersoft, has encountered unrealistic attitudes towards the “deadline guarantee” quite a few times during her 30 years spent working in the industry:

“Guaranteeing a deadline is never anything more than a fantasy. In 99 per cent of cases, a project’s requirements will change over time. Or, if the requirements don’t change, the circumstances will,” she says.

That’s why you should always use an agile development method, Sara explains. That is, you should divide the project into small interim goals and take one step at a time. While this approach might seem needlessly complicated, it pays off in the end. She adds:

“In an uncertain and changing world, tackling projects this way gives you an advantage: you get direct and rapid feedback and can apply the brakes and redirect your project before it’s too late if you realise there’s a problem. The ability to change tack this way is often very valuable, since you save both time and resources.”

That said, if an agile approach is going to work, everyone involved in the project must fully comprehend what it means to work on an agile basis.

“One common misconception among clients is the belief that they can pitch a basic idea and then let others do the heavy lifting for three months, after which time they will receive a finished product. Unfortunately, that’s not the way it works. If you want short feedback cycles, then you also have a responsibility to shoulder throughout the development process. When this kind of regular contact is missing, it’s easy for delays to occur,” Sara explains.

…in the right direction

To avoid having everyone involved be convinced that they know how to create the “dream house” you’re building – and then promptly start following their own plan – it’s important to make sure that everyone shares the same idea of what your dream house will actually look like when finished. This basically boils down to further specifying and visualising the requirements. By doing so, you ensure that everyone has the same road map for where you’re heading.

“You need to describe what users want to achieve and begin visualising the end product from a number of different perspectives at an early stage,” Sara explains.

In the same way that black and white building plans comprised of measurements and figures are supplemented with images and models for the sake of clarity, miscommunication between product owners, developers and designers can be avoided by using user interface prototypes and clear descriptions in both text and images.

Follow the “user compass”

The next step is to test your product as soon as possible. Get it out onto the market, or release it for use by a small group of users – whichever is most appropriate. You can then adapt it based on user feedback and needs. Get rid of anything that doesn’t work and add any missing features.

“You work based on a backlog of tasks that are prioritised and re-prioritised on an on-going basis. Basically, it’s a list of requests,” says Sara. “You need to constantly refine your plan by taking a closer look at the requirements that are next in line for implementation. For those that are still a way off, you draw up a rough outline instead. Many of them will turn out to be irrelevant in the end, since the requirements imposed by the market, clients and others will change during the life of the project,” she concludes.

When it comes to large projects, the aim is to create a minimum viable product (MVP) that can be tested in the market as soon as possible. This approach lets the project generate added value early on and allows you to adapt development work on an on-going basis based on current conditions and real-world circumstances – a much better alternative than trying to predict the future and create a finished product from the start. (That is to say, “finished” at least until it is tested, when you will realise that, unfortunately, you weren’t psychic and need to start again from scratch.)