Have an idea? Great, let’s dive into coding! Oh, wait…

Povilas Korop
Successful IT projects
2 min readMay 23, 2016

A lot of IT projects fail to be delivered within time, on budget, or even at all. There are a lot of reasons for that but I see the most important one and I want to emphasize it. It’s lack of proper analysis.

A usual workflow for a project looks like this.
Step 1. An “idea-guy” (or a company, whatever) goes to market and shouts “Hey, I need a project X! Who’s available?”
Step 2. Vendors are competing to win the project, trying to deliver the best offer. And they often think that the quickest company to provide an offer wins it. Which means cutting corners on analysis of the client’s needs.
Step 3. After a few interviews, the client chooses the developer to go with, and ONLY THEN they spend time to analyze all the details of the job. And that’s not the worst case — they might just dive into coding, thinking they would “solve the obstacles as they appear”.

Fail.

So, first rule of any project: don’t start ANY coding before you actually know what you’re doing and why. Not only that, you need to be sure that you actually NEED what you’re doing — quite a lot of functions can be postponed for later stages or even rejected.

So in this case, who takes care of actually analyzing the need of the client? Should the client come up with a detailed specification, or should the vendor take a week (roughly) to properly write out the detailed plan?

Actually, both. Both parties need to do their homework. But TOGETHER. That’s weird, right? How can business guys know how to code, and vice versa?
But in real world, client does need to understand at least the basics of IT infrastructure and to understand how developers operate and what is their process — it will help in managing the project.
Likewise, technical team needs to understand business goals and processes of the client — only in that case they can deliver quality technical result.

So by working together on the final requirements specification (or whatever name you put on that document), they discuss some important details, change scope a bit, figure out the first version/milestone etc.

The funny thing is that this conversation always happens. There always comes a point of more detailed discussion between client and developer. But if it appears only on the first phase of testing the actual product…

The most common argument against spending too much time on planning phase is “we don’t have time for it, we need results next week/month/yesterday”. Here’s my sarcastic answer to that.

Now, on a serious note, you have an idea for web-project? Need help in analysis, planning and development? I’m free for consultations — contact me on Twitter or email to povilas@laraveldaily.com

--

--