Web Projects that Succeed
No one has ever come to us with a project they started with some other developer that failed in the Planning Stage. During planning, everyone is excited, and the developer can say "yes" to every request. However, decisions made in a pre-work Planning Stage are always based on limited information and unrevealed assumptions.
This is what causes project to fail in the Execution Stage. The clients disengage, and naively expect that all their hopes and dreams will magically come true without any intervention on their part. Only when the developer comes back with a disappointing delivery many weeks or months later does the client realize that the two were never speaking the same language.

- Client
- Developer
- End Users
- In-house IT Staff
- User Support Team
Software development, including and especially website development, is a journey in which the destination always seems more real than it truly is; to get to the promised land, everyone needs to plan for detours, pit stops, and map revisions.
During development, we have a mini planning meeting with our clients every two weeks at most, to review:
- What tasks have been done since the last review?
- What have we learned since the last review?
- What tasks are expected to be completed before the next review?
- What roadblocks are we facing, if any?
Both the client and the engineers must answer these questions. This allows us to be flexible in our process, and accurate in our decision making.
Every project requires change mid-stream. In over ten years of web development, I have never once seen a project that was both satisfying to the client AND fully matched the original specifications document. It just doesn't happen, largely because clients and developers both have expectations and assumptions that can't be communicated until they are truly sitting together and looking at a real, usable piece of software.
Change is most expensive when you fail to plan for it. When you plan for features instead of planning for change, you are planning to fail, because the features that you can imagine now are a dim shadow of what will become crystal clear once the real work has begun.
Horizontal and Vertical
Finally, I'd like to point out that what we're talking about here is not the difference between "Vertical" and "Horizontal" development methodologies. In vertical development, the team tries to determine all of the user requirements in advance. In horizontal development, the team focuses on one set of related requirements, and does not consider other requirements until a system has been delivered which fully meets those defined requirements.
At Ninjitsu Web, we use a hybrid approach. We will work with you to broadly define as many requirements as possible at the beginning, but work will commence on the assumption that requirements which are scheduled later in development may change significantly. So rather than delivering a complete and final sub-system with every iteration, we will deliver a series of working prototypes, which will be polished and tuned for final release once the entire system has been prototyped and proven to be capable of fully satisfying the client.
Resources
Here are a few resources that expand on these ideas:
-
This short essay provide an excellent explanation of exactly why over-planning is a waste of time: There's Nothing Functional About a Functional Spec
- In the long run, Prototype-then-Analyze-and-Adapt ("Agile") projects are also more cost effective that Plan-then-Build ("Waterfall") projects. Here's a brief video explaining why:
Why Does Agile Software Development Pay?
Ninjitsu Web further maximizes these benefits by fully guaranteeing our estimates at the beginning of each iteration. There is no +/- 20 percent. You will not pay for a single minute over our estimates once a phase of work has begun; however, you might pay less. As often as possible, we will present for you multiple strategies for accomplishing a particular task. Clients who consistently choose the simpler of two approaches consistently receive invoices below estimate. Cost control is entirely in the client's hands.
- Here is a dramatized take on the big idea: Agile vs. Waterfall: A Tale of Two Teams
We're on "Kate's" team, and we look forward to having you join us there.
If you have specific questions about how best to approach your own web project, please feel free to Contact Us.
Matt Chapman - Owner, Ninjitsu Web Development

This work by The Matt Chapman Company, LLC is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
- Login to post comments

