Table of Contents
The Story We’ve All Heard
The Kickoff Meeting
At the beginning of the project, at the project kickoff meeting, the big boss walks into the room and tells everyone that we need the project done by the end of the fiscal year, six months from now.
Team morale is high. Why wouldn’t it be? We still have all of our budget. The team we put together seems quite eager and competent. Everything will be fine.
The Analysis
The project is then sent to analysts. The analysis phase starts and is expected to last for two months. Why two months? Because there are three phases (analysis, design, implementation), and six months divided by three phases equals two months.
Two months later, the analysis phase is done on time. The analysts did their thing and drew up some nice diagrams and charts that made everybody on the project team feel like they knew much more about the project. Everybody is pretty confident things are going well.
The Design
The project is then sent to designers. The design phase starts and is expected to last for another two months.
During these two months, some requirement changes happen. New features are added, old ones are removed, and some are changed. Ideally, we’d send these features back to the analysts for re-analysis, but who has time for that? We have a deadline to meet, so our talented designers hack these changes into their design directly.
Two months later, the design phase is done on time. The designers did their thing and created wireframes, mockups, and sometimes even prototypes that are pleasing to look at. Everybody on the project team feels even more confident things are going well.
What have we spent, and what have we gotten so far?
Let’s put a pin here and see where we are with the project. Schedule-wise, we are 2/3 into the timeline. Cost-wise, we are likely 1/3 or 1/2 into the budget. Ok, what about the value gained?
So far, we have nothing. Unless the app is in the hand of the user, a software project generates zero value.
But all these diagrams and mockups have to mean something. We are sure that with these analyses and design deliverables as input, the implementation phase will go well. So we are really just supercharging the project and will get our return once the implementation is done, right? One can hope.
The Implementation
Let’s continue. The project is sent to developers for implementation. The implementation phase starts and is expected to last another two months because that’s all we have left.
During the next month and a half, some more requirements change. New features are added, old ones are removed, and some are changed. Ideally, we’d send these features back to analysts and designers for re-analysis and re-design, but who has time for that? We are rapidly approaching our deadline.
Unlike the previous two phases, which don’t have defined completion criteria, there’s no ambiguity as to whether the implementation phase is done. We can’t pretend it is just because time is up.
So our talented developers try their best to hack these changes into the code directly.
Two weeks before the deadline, we look at what we have built and realize it is nothing like the pretty diagrams and wireframes. On top of that, the remaining work doesn’t look like something that can be done in two weeks. So someone finally rings the bell, and the big boss, for the first time in the project, is told that we are facing some challenges.
“Couldn’t you have told me this sooner? What did I pay you to do all those analyses and designs for? And why are you telling me this when we are two weeks before the deadline and almost out of budget?”
The Inferno
What happens next is brutal.
Stakeholders are angry, pressure is high and people are working overtime and still can’t make the original deadline.
New team members are introduced, hoping more hands will get more work done faster. However, that just lowers productivity because new members know nothing about the project and pull senior resources away for training purposes.
Several new project completion dates get thrown out. You hear, “We will do better next week.” “We think we can finish the project two weeks from now.” “We hope our new members will catch up soon so it will put things back on track.” Back on track of what? At this point, it has been ten months since the beginning of the project.
When the app finally gets deployed, it sort of does what we set out to do. Everybody is unmotivated. Some finger-pointing happens, but nobody cares anymore.
What went wrong?
Maybe not all software projects turn out like the story above, but there are far too many that come close. Several things went wrong in the story outlined, but in this article I want to focus on the beginning of the project. Let’s look at how we start a project.
First and foremost, I want to emphasize that there is nothing wrong with spending effort on analysis and design; both are necessary. The problem is the timing of these activities, and the level of detail to which they commit before implementation starts.
At the beginning of a project, a lot of information needs to be fleshed out. Because it’s early, much of the information we gather is not concrete – i.e. “We think doing this will improve our efficiency.” “We think training users to pick up this new way of working will not be a problem.” “ We think most of the time, this proposed workflow/design should work. The exceptions should be rare….”
There is a lot of hypothetical information here. This sort of loosey-goosey information gets captured and thrown into some serious-looking artifacts, like diagrams, charts, mockups, and wireframes. All of a sudden they look concrete, but they are not.
Once the implementation team starts building the app based on this serious-looking but not concrete info, we truly put them to the test because the user will tell us whether the features built upon them actually work. Some would. Most won’t.
What’s worse is that most of these deliverables capturing non-concrete info won’t be updated down the road due to a lack of time/resources. Not only are they not contributing to the project, but sometimes they become misinformation and lead the project in a worse direction.
Remember that all deliverables that don’t contribute to the final functional software generate no value.
So what happened is that we spent a lot of money and time upfront, yet created deliverables that don’t contribute much to the final software (a.k.a waste). We invested more and got less in return, which ultimately generates lower ROI (Return on Investment).
The Better Way to Kick Off a Project
Instead of spending half of your project budget before seeing one functioning feature and producing a bunch of waste, you can spend 10% to get the project started, and get more in return.
How, you ask?
Start with producing less waste. Only create deliverables that will be useful in the future by only committing to certain information at this project stage.
So what do we do?
Lay Down the Initial Project Plan
This is not an extensive project plan that takes several weeks to develop. It’s a short list of features called “stories,” that are estimated, prioritized (based on business value), and tentatively scheduled for the next few weeks for implementation (in certain cases).
That’s all we can be certain of at this project stage, so that’s all we produce and commit to.
As underwhelming as it may seem, this initial plan made of stories sets up the project for success. The stories themselves are tangible representations of your project. You can add new ones, delete old ones, or move them up and down in priority. The process of writing, estimating, planning and designing stories never stops. Following this process means you will always have an up-to-date project plan based on the information you are certain of at the time.
Because stories are estimated (and will continue to be re-estimated), a lot of data is produced for managing the project:
- By tallying up all the estimates of remaining stories, everybody (including the big boss) can tell how much work is left in your project (remaining scope).
- By measuring the estimates given to stories completed each week, everybody can tell how fast we progress (velocity).
- And with elementary school math, you get the projected completion time if you use the remaining scope divided by velocity.
The beauty of having this data is that you don’t just get one chance to be told that you are screwed. You get chances every week, so you can manage your project, adjust the scope, and manage the outcome and expectations.
Ready the Project Logistically
There’s nothing worse than being fully ready for implementation, and then realizing that some issues have to be sorted out by IT weeks from now.
Therefore, at the beginning of the project, we should get whatever we need logistically for the project. This includes but is not limited to:
- Development and testing environment for the software
- Code repository
- Requirement and task management environment
- Document repository
- Communication plans
- Responsibility clarifications
- All kinds of access
- And more
Create a Tentative Initial Design
The design produced at this stage should be based on the list of stories. The stories should provide some guidance for the upcoming implementation but shouldn’t be too detailed to be modified and adapted to the latest needs.
Some design deliverables we tend to produce at the beginning of a project include:
- Some diagrams capture the high-level desired workflow and data flow
- High-level architectural decisions, such as how to approach certain integrations and choosing tech stack
- One or two mockups to set the tone for the overall look and feel of the system
- And sometimes, when dealing with particularly challenging projects, proof of concepts.
All these deliverables are either at a very high level, so they are easy to be kept up-to-date, or they are intended to be throwaways (like a proof of concept).
Effects on ROI
There are three reasons the second method increases ROI.
First, a dollar today is worth more money than a dollar tomorrow. By spending less time before a project creating in-depth plans and designs, we can start implementation sooner. Keep in mind that unless the app is in the hands of the user, a software project generates zero value/return. The sooner we can start implementation, the sooner some features of the app can be sent to users, and the sooner you start getting returns on your investment.
Second, getting the app to the user more quickly also generates a better overall design, which leads to higher returns. Getting the app to the user and getting their feedback is the most effective way of turning unproven information into concrete information. Driving your project with concrete information is how you get the best possible outcome for your project. And by definition, the best possible outcome, which is almost definitely different from what you thought you would get at the beginning, is still the best possible outcome you can get.
Last but not least, reducing waste increases ROI. By only committing to concrete info, we channel our effort into creating functional apps rather than creating feel-good documentation/designs.
Conclusion
By only committing to concrete information and investing less at the beginning of your project into producing waste, you give yourself a much better chance of success. Sounds too good to be true? Well, contact us and let us show you how it’s done.