What Makes a Project Successful?

The other day I had the opportunity of introducing agile to a client. I usually do that by walking through how Scrum works; backlog, sprints, sprint planning and spending time talking about organizations and how they deal with change. 

That approach usually works well, but this time I decided to use another approach. I simply posed this question to the team:

What makes a software project successful?

After a short, but great discussion they came up with the following answer:

• Specification - So we know what to build.
• Estimation and milestones - How long will it take.
• Project manager - Keeps project on target.
• Resource utilization - So people have things to do all the time.
• Testing - So we know it works.

Quite possible it was the first time they had ever talked about it, so I'd say this was a new experience for them. 

To make it a bit more interesting, I had prepared a list of my own what I think is most important in a project:

• Collaboration - Between team members and customers.
• Transparency - What is the plan, and what is going on right know.
• Motivated team - Keeps us focused and energized.
• Prioritization - What is the single most important thing to build right now.
• High quality - We care for our work and are proud of what we do.
• Reflection - So we can improve how we work.

Note the striking difference between these two lists. The first contains mostly things related to detailing, planning for the future and delegating tasks. My list, on the other hand, is mostly about people and how they interact. I'm not saying theirs are wrong or anything, just different from what I consider important.

We then then compared these views, the discussion that followed was a little bit of an eye opener for them. Looking at projects as "people working together with the same goal" opens up an entire new view of what is important for a project. 

Asking about why collaboration is crucial and why I think transparency is key to success led to even more insight. One such insight was that they had been looking for specifications and dates because they often felt uncertain, which in turn prompted them to make ad-hoc guesses leading to wrong decisions. Adding more specification details in an early stage is not the cure for that. Working closely with the customer and being transparent with progress is.

So in the end, using this approach turned out pretty well. It hopefully built a platform for more concrete discussions about how to build software based on these powerful ideas.