Have you ever heard crickets chirping when you announced your product? Sucks, doesn’t it? A lack of enthusiasm from customers or even your own sales team is a sure sign that your product fails to meet demand. While it’s true that a project is a success if it meets the needs and expectations of consumers within the constraints of the project, it is more accurate to say that a project is only considered a success if it’s perceived as a success. In order to have your project perceived as a success, you need to manage expectations. And the way to manage expectations is with clarity. A successful project needs everyone involved with the project to have a clear purpose, clear priorities, clear use-cases, clear estimates, and a clear understanding of dependencies and uncertainty. Fully expanding these points could easily fill entire articles (or books), but here’s a basic recipe for making a software project successful.

1. Clear purpose and consumer buy-in
Granted no matter how great your product is, you’ll probably never hear screams of adoration or see people throwing their underwear at you on stage. But when you hear exclamations of “Yes!” from the audience, mutterings of “Awesome!”, and even grumblings of “About time!”, you know you’ve built something they really want.

Constraints like time and money are nice (and in fact, necessary), but they aren’t the purpose of a project. A clear purpose answers questions like “Why are we doing this?” “What value does this provide to customers or the organization?” Those answers need to be broadcast to everyone involved in developing and consuming the project.

A clear purpose impacts the beginning, middle, and end games of a project. It’s probably evident to you that the design or architecture of a project depends on clear goals, but a clear purpose goes deeper than that. The success of a project is determined by achieving a clear purpose and meeting specific goals within established constraints. Everyone needs to share the specific definition of success, otherwise the project will not be perceived as successful. “Everyone” is not just the project initiators, managers, and developers, but also the actual users and sellers of the product.

A clear purpose also accelerates the execution of a project. Not only does a clear context allow line managers make decisions more quickly in the field, but a clear purpose also makes the workers themselves work faster. Developers (like everyone else) really want to see how they are making an impact. Knowing why they’re doing something motivates employees. Motivated employees work more efficiently and effectively.

2. Clear priorities
If everything is a priority, then nothing is a priority. Yes, of course everything is of critical importance, but what does upper management want first? Which feature or task do they want second, which one third, and so on? Features, user stories, and tasks should be ordered from most wanted to least wanted. They should be arranged in a pipeline where the top of the list will be worked on first, second item second, etc. Work orders should NOT be delivered to team leads or task managers organized by categories (i.e. 4 tasks that are marked Critical, 7 that are Important, 3 that are Nice To Have). Organizing by category is a good place to start to organize your thoughts, but you want to deliver a pipeline of clearly prioritized tasks to implementers.

3. Clear use-cases
A use-case describes the behavior of a feature as a user interacts with the app. A use-case describes how the user will use the feature, what the user should experience, and how the system will behave when the user interacts with it. Use-cases can be functional recipes (“first the user clicks this, then sees that, then pushes this button to make this happen”) or they can be organized as pictorial storyboards which map out the workflow of an app. They’re dead simple. Adding stick figures is a nice touch, but not necessary. Remember use-cases are not your product’s sales brochure, they are not a list of sub-features, you need to be clear about what you want and flesh out how it should behave. A clear set of use-cases not only speeds up production by letting testers design tests around them, but it also lets line managers and developers make decisions more quickly on the fly. Clear uses-cases often expose design and functional problems before time is wasted tasking, estimating, and implementing them.

4. Clear understanding of dependencies
Projects almost always have dependent tasks. A dependency is where one resource needs to wait for another resource to finish before they can begin. A critical path is the chain of dependencies that has the most impact on the length of a project. Even if you are an agile shop, you must take into consideration dependencies and critical paths. If you are a time-box-driven agile shop (such as Scrum or XP), you need to think of a sprint or iteration as a mini project with its own dependencies and critical paths. If you are a pipeline-driven shop (such as Lean or Kanban), dependencies and critical paths will show up not in failed time-boxes, but in bottlenecks in the pipeline.

For example, you may look at your work load and see 620 hours of work for a set of features that are to be unleashed on the general public at the end of the iteration in two weeks. You have 80 hours to get everything done, and you have 8 developers, giving you a total of 8 * 80 = 640 man-hours of work, therefore you should get everything done with time left over for foosball, right? This is making a huge assumption: that all developers can work concurrently without waiting for anyone else to finish before they can begin.

Take this scenario: if one developer or tester’s task is estimated to take 5 days, but he has to wait until another developer finishes his task block which is estimated to take 7 days, the sprint has already failed. Let’s do the math: a two week sprint is 10 working days, the dependent tasks are 5 +7 = 12 days, which you may remember from grade school, is greater than 10 days. In order to prevent the sprint from failing, the dependent feature will have to be moved to the next sprint, delaying its release another two weeks. You can avoid manpower downtime by moving other tasks from the backlog into the current sprint or letting developers check in partially finished code (as long as it doesn’t break anything), but stakeholders will need to be made aware ahead of time that the higher priority feature won’t be completed until the next iteration.

You might think in this scenario that you can simply have the developers agree on the programming interfaces early on, then finish development later based on the interfaces, allowing them to develop concurrently. But what is often the case in tasks that take several days, designing the interfaces and working out the architecture is easily 80% of the development time. The time it takes to type out the implementation of the interfaces and work out the internal details is often fairly short. This means even if they were perfect in their design of the interface and needed no rework to get each others’ code to work together (fat chance), they still wouldn’t have much time to work concurrently.

Sometimes dependencies are not known beforehand and pop up during the project. Developers may need to wait for approval for purchases of licenses for software tools or clarification of a use case from a business analyst. QA may need to wait for another server to be brought online by the network manager to do load testing. The coffee machine may be down, throwing everyone into the DTs. For tasks that lie in the critical path, team members (or a team lead, scrum master, or chief whip) will need to be particularly vigilant in staying on top of blockages and getting them cleared so dependent work can resume. Any delay to any link in the chain of dependencies in the critical path delays the whole pipeline and jeopardizes the success of the project.

Ignore dependencies at your peril.

5. Clear estimates and a clear understanding of uncertainty
Decision makers need to know how long something will take to build to see if it’s worth the organization’s while to produce it. Building a time machine would be extremely valuable to a company but if nothing like it has ever been done and it’s estimated to take 120 years and 300 trillion dollars to build, it’s just not worth it to even start. However, being able to broadcast product releases to Facebook or Twitter may be not be as valuable as a time machine, but if it took only a few minutes to build using free tools, the company would probably want to pursue that project.

Non-technical people often have no idea how long something will take to build. Sometimes they think something will take a very long time when it can be done very easily, sometimes they think something is very easy but is actually extremely difficult to implement. It’s up to the technical staff to give them estimates.

Estimating how long something will take to build is difficult to do even when variables are extremely well known and the environment is draconically controlled. Even if a company has built thousands of the same exact car with materials that haven’t changed in decades, using robots that have been bolted to the ground since the assembly line was built years ago, estimates for how long it takes to build that car are still off, sometimes way off. Software development is never as straightforward as assembling a car from prefabricated parts. It’s a lot more like designing and prototyping the car, requiring creative solutions invented on the fly using a wide variety of tools and resources. Bricklaying development that has been done a hundred times before is going to allow very accurate and precise estimates. Innovative development doing something never done before with tools never used before is going to allow much less accurate estimation. Estimating the length of a software development task is an art at best, and at worse it’s a dark art filled with outright lies and deception.

So how do we mitigate these issues? Good management practices and good relations with workers eliminate deliberate inaccuracies. Improving coding design and following best practices reduces uncertainty in development and testing estimates. Breaking tasks into smaller pieces tends to make those pieces easier to understand and quantify, and therefore easier to estimate. Granular tasks also provide faster feedback to everyone involved, letting you know sooner rather than later when the project is going off track. Another way to improve estimates is to have another set of eyes look at the task. Sometimes it helps to get a small design team together to come up with creative ways to tackle the problem and therefore provide a revised estimate.

As you break tasks down further and further, or include more developers in the estimation task, you are actually moving more and more deeply into the implementation phase of the project. You are no longer just estimating the task, you’re actually starting to design and architect the system, which takes more and more time. The closer you are to actually implementing the task, the more accurate and precise your estimates tend to be. A 100% precisely accurate estimate is therefore a task that is 100% completed.

Managers need to be clear about what estimates are. Estimates are educated guesses. They are not commitments. Breaking down tasks and other techniques do help with creating estimates, but don’t fool yourself, they are still rough estimates and it’s dangerous to bet the farm on them.


The success of a project comes down to clear perceptions. A project is successful only if it’s perceived as successful with an agreement of clear purpose. A project can only succeed if it has clear direction in the form of clear priorities and clear use cases. A project can only succeed if there is a clear understanding of task estimates, dependencies, and uncertainty. In short, clarity is needed for the success of a software project.

« »