How many times have you started a project with a well thought out plan only to have the plan fall to the wayside shortly after starting it?
Here are a few reasons that cause us to deviate from the original plan:
- Technical issues are uncovered and the plan has to be adapted
- Developers or people that were excluded from the planning process have a better idea
- Someone changes their mind
- The team learns new techniques or finds new tools
- Users provide feedback that doesn't align with the original plan
- Something wasn't thought out well enough. Whose brain doesn't turn to mush after a full day (or more) of planning?
Once the perfection of the plan (and especially the documentation) has been compromised, the tendency is to abandon it. Have you ever heard of the broken windows theory? This theory states that if an abandoned building has no broken windows, vandals will leave it alone. However, as soon as the first few windows are broken without repair, vandals consider the building fair game. Soon, the building will have many broken windows and be overtaken by squatters building fires inside for warmth.
This theory applies to documentation and planning as well. We'll stick with the plan and keep the documentation up-to-date until a few "windows" are broken and not repaired and the documentation is no longer accurate. Then it begins to be more and more difficult to keep the documents up-to-date, until they become a dusty pile of papers that nobody ever looks at anymore. Bad data is worse than no data right? Doesn't it also stand to reason that inaccurate documentation is worse than no documentation?
Don't get me wrong, I'm not advocating abandoning the idea of documentation or planning altogether. I'm questioning the sanity of doing it all up-front. At Pinnacle, an Advanced Imaging Solutions company, we have adopted many of the tenets of the agile programming methodologies, many of which have been borrowed from lean manufacturing practices. One of the primary components of agile is in the area of planning. Agile advocates doing only high-level planning up-front and the more detailed planning along the way. This is called iterative development, or more accurately, iterative planning. Why fight the ever-changing nature of software development projects when you can embrace it?
Another tenet of agile is the Japanese concept of Kaizen, or continuous improvement. Doing our planning iteratively gives us the opportunity to improve our plans frequently. We're always learning things as we go, so why not apply what we've learned as we continue working on the project? Our clients have a lot of opportunities to provide feedback. They are constantly involved in the planning discussions and do the final testing of all new features. This gives them the opportunity to discover a better approach than what the original plan specified.
When creating the original release plan, we try to deploy beta system releases to actual customers as early and often as possible. Not only does this provide us the opportunity of getting feedback early and often, it also has the added benefit of providing actual value as early as possible. For example, we are currently working on a dealer portal for a manufacturing customer that will allow their dealers to enter orders, aided with a sophisticated configurator, to ensure the integrity of the order. Their current order-entry process did not have any sort of integrity-checking processes to ensure the unit can actually be built as ordered.
The system isn't at a point yet where we can release it to dealers, but they are already using it internally to enter production orders into their system. By releasing a function of the system to a small set of internal users, we were able to get valuable feedback from actual users who have already begun to benefit from our work.
We don't want to discourage the creativity and ingenuity of the team so we leave enough room for plans to change. It's not uncommon for some of the best ideas to come along after the project has started. That is why we make plans when we start a new project, but we intentionally don't fill in all the details. It's more of an outline leaving plenty of room for feedback along the way.
With iterative planning, there are very few surprises by the end of the project. There may be some smaller ones during the project, but you can rest assured there won't be any big ones at the end. Sometimes, the end result is totally different than what was originally envisioned, but that's a good thing! The further we end up from the original plan, the further off we would have been if we had done all the planning up-front and created a system from the original set of blueprints.