This blog post is result of an interesting conversation with one of our clients.
Software & Web Development is all about making the tradeoffs. Most of the development teams trade the scope of the project with the schedule. But the most important & interesting tradeoff is between “schedule” and “cost”.
On one of the projects where time was not our friend, client came up with a plausible solution – “ Why don’t we put more resources to work on the project. If 6 guys are taking a month to do it, 12 would take 10 days to do it. ”
I enquired why 10 and not 15 days. He replied “Synergy!!”
This seems quite a simple solution to a much complicated problem.
After years of experience, we have come to understand that this is not always the best solution to this problem, and Mr. Brooks agrees with me on this. Brooks’s law is a claim about software project management according to which
“Adding manpower to a late software project makes it later.”
Well there are cases where this does not hold true like –
- Project was understaffed when it started, probably because of miscalculation on the part of the initial analysis.
- The team didn’t start working on some components that could have used more resources, given the components were loosely coupled to core functionality.
- External expertise might help team to implement off-the-shelf solution, team didn’t know of in first place.
Why the predicament?
In a race between “schedule” and “cost”. Schedule wins it. Companies want to complete projects at low costs but not at the expense of schedule.
This is one of the fights where every product owner has to get involved in. One cannot let the cost of project ”run wild” or let the product stare into space for too long. Most of the time, it starts with getting things done on schedule and ends with fighting off cost in later stages of the project.
Many a times companies hold strict schedules where cost and pain are trivial. Death marches to deliver the project are expensive, both on dollar cost and stress on the team.
What is the solution then?
In this particular case of the client, I was referring to earlier, we found quite an interesting solution. Conventional wisdom says that Designers should work closely with everyone on the team. Ideally the designs should be done in same sprint as rest of the development work. This will shorten the schedule but has consequences when there are reworks because of design inconsistencies and programmers sitting idle waiting for the designs.
We let the part of design team work way ahead of the programmers to create designs that will help recognize features that creep in later stages. The design team created basic graphics rather than striving to create pixel-perfect designs. The basic graphics would let us get the feel of the product, but not to the level of details that will drag us into many changes as the details start to evolve later.
As you might have come to the conclusion by now that these steps will be unique based on your project requirements.
I’d love to know which one you think should win – “schedule” or “cost”? I bet you want both of them to win for your next project. Share your war stories in the comments.