Starting a project

Let’s go from zero to hero by looking at the pieces needed for a Project that becomes a Product that becomes something useful.

You are going to build a great product, but I got news for you. It all starts as a project. It’s fine. We can call it Product, MVP (Minimum Viable Product) or what we want, but it’s going to start as a project first.

Many companies are discussing the why and what the benefits of doing this particular activity would add. Check out Budget for some information about NPV (Net present value - what is it worth now?) —calculations and Build or Buy.

There are many Project management methodologies who can assist you in starting, planning, implementing, testing, releasing and closing your project. There are also some methodologies who runs this in iterations, ie short repeats, instead of longer “phases”.

What this means to projects has big implications to how you set it up, how you run it and how it’s delivered. 

For the sake of completeness of this little book, I will quickly explain classic Project management, aka “Waterfall”. Imagine a river. This is your project process. You always move down the river and you are not going back to change things as you go, it’s fixed and settled.

So you move further and go in to different phases, like the implementation phase where all the code is supposed to be coded, and later the testing phase when it’s supposed to be tested. Everything is based on up-front specifications that was written before your started the Project.

You knew exactly what you wanted to build, down to the last button. So you spent months putting this in to a document, then your Senior developers or Architect helped you write the Functions in the Functional Specification document. Then in the Implementation phase you build exactly what was in this specification. Then you test that it’s working like it was specified.

This has never ever worked in any tech projects. The best deliveries of these kind of projects produced an application that did exactly what it was intended to do, but did not take any findings or ideas in to consideration which was found during the development.

Also, time passed during the Project duration, and you lost some chance to show this to a potential customer and get valuable feedback. You have now built something that you have not tested against any real user. I’m going to go out on a limb here and say that it’s probably not going to be what you wanted.

Read more in "The CTO Playbook" available on Amazon/Kindle.