Why having a vision is key in software project management

From March to May 2016, we are teaching the course Software Project Management at the Free University of Amsterdam. In eight weeks, students learn the fundamentals of project management and are creating their own project plan for a software project of their choice. In the course we devote the first week on the project vision. Many inexperienced software project managers forget to articulate and share a project vision. As a result projects lose track and fail to deliver. Here is how you can avoid this by creating, sharing and updating a vision.

This article is part of a series that accompanies the university course on software project management by Joost Schalken, Jeroen Arnoldus and Sieuwert van Otterloo. The series consists of  (1) creating a vision, (2) project scope, (3) managing non-fuctional requirements, (4) effort estimation, (5) risk management, (6) planning and scheduling, (7) organisational change,  and (8) recommended project management books and articles.

Creating a vision

A project vision is a short document that summarizes the ‘why’ of a project. It is intended for everyone, so it is not about IT. Rather it is about the change in how people work that the project is trying to accomplish. If you have never seen it before, please check ‘Start with why’ from Simon Sinek.

What the project vision looks like depends on the people that pay for the project. If it is a text-focused company, use a word document (e.g. a two page memo). If it is powerpoint-driven company, use powerpoint. If the ultimate goal is to convince customers, you can also make a short video about the product, or a presentation with example screens. A well-known example is the dropbox video pitch that dropbox founder Drew Houston used to convince investors to invest in their product. It might seem boring, but seeing this fake product gave everyone an insight in what the project was supposed to accomplish, far better than a long vision document could do. What is most important is that the vision should not be about the software. It should focus on the process and people that the software is about. So if you would like to build the ‘Airbnb for boats’, the vision should tell us about boats, how people use boats now, and what how they will be satisfied about having the right boat.

If you are doing an innovative project, you can learn a lot about project visions from the Lean Startup method. For instance, you should focus on a very small, specific customer group at first. You should also get out of the building and base your vision on actual interviews with the target audience. In a more traditional project (delivering exactly what has been asked), the vision should explain who will use the resulting software, and how, when and why they will use it. This will help in making the right software.

Sharing the vision

In many organisations, project visions are created but they are not shared with all people involved in the project. Because the project vision is created in the beginning, it is assumed that it is only useful in the beginning and only shared with the team members who are joining the team at the start of the project. The project vision is important for all stakeholders, whether they are in the team or not and regardless of when they become involved. Ideally the vision is made public, so that any can have a second look if needed. Some teams that have a project room, make a poster based on the vision and put it at the wall. This way, any visitor knows there is a vision and is invited to take an interest.

Note that the creation of a vision is the first decision point in a project. If it is not possible to create a simple vision statement that all stakeholders agree with and are excited about, the project owner can conclude that the time is not yet ripe for the project, and postpone the start of the project until a clear vision has been agreed.

Updating the vision

Updating the vision of a project is a tricky subject. In theory, the vision should not change. It should contain a vision only but no practical matters. It should describe the ‘true North direction’ according to a popular metaphor. Supposing that the goal of the project is to reach the North Pole, the vision describes where the North Pole is. Anytime the team encounters an obstacle and has to make a detour, the vision is used to get the team back on track.

In practice people learn a lot during any project. The initial vision is not perfect. During the project, the team and project manager should keep listening to the users and customers and adjust the vision according to new insights. This can go both ways: if they discover that customer have some unforeseen needs (e.g. they will never book a boat without insurance) the vision might be expanded. If they discover that certain parts are not needed (people are willing to share small boats with their neighbours at no cost) the vision can be simplified. It is fine for a knowledge to evolve during a project, and in each case the vision should be updated.

Next steps

After creating a vision, one has to work on a plan for realising the vision. In the VU software project management course, the vision is the first chapter of the project plan.  All chapters are created in a presentation format and groups will present their plan during the course, so that they get immediate feedback. This way the vision and rest of the plan are communicated clearly to stakeholders.