Every project plan has some elements in common. Before starting to create the prototypes, drawing wireframes or hiring coders, it’s important to:

1. Define what you will do
2. Divide it in small tasks
3. Define who’ll do each part
4. Assign an amount of time to each one of them (start and finish dates)
5. Create a way of measuring progress
6. Register tasks finishing dates
7. Tasks needed before a given task begins
8. Create a timeline
9. Assign someone to control and manage everyone’s activity

Avoid failing the project by careful planning
There are several reasons why projects fail, and most of them can be avoided by careful planning.

Not enough time or money: Without proper scheduling and budget control, it’s easy to have a project dismissed due to lack of resources. Besides, even when they not fail, the final project can be sloppy, with bugs or dysfunctional if this kind of planning fail. That’s why it’s very important to have everything that’s needed clear on every team member’s mind before starting.

Poor communication: A client asks for a simple website, and then wants to add functionality that’s hard to implement; the designer makes a wireframe awful to code; the coders say it’s impossible, but it isn’t. Everyone saw that situation sometime, and most of the time it’s a problem of communication. Websites and software can be pretty complex sometimes, and words aren’t very specific to describe them, or jargon can be very hard to understand for non-technical people. It’s important to always speak clearly and make sure that everyone understands what’s being expected and required from them.

Inadequate testing: Most of the time, due to problems in timing. Since launch date is so close, people decide to simply launch it, and then fix the errors. Sometimes it works (as Google Beta apps do), but others they fail miserably. Testing should be done, and it’s even more crucial for first time launches.

Lack of quality: Those come often from time management problems. Not enough time to test, to guarantee that everything is just as it should be, so we’ll correct everything as the problems come. Sometimes works, sometimes it’s a trainwreck.

All of those problems should be avoided with careful planning.

About the Author

How to define, validate and review applications before starting to code are his thing. He is interested in everything related to web, mobile and desktop apps and how to prototype and simulate them before development starts. After hours he’s flexing his math muscles.