A successful project manager on a software project does a small number of things well: gets agreement on what “finished” means before work starts, keeps decisions moving, looks at working software instead of status reports and tells people bad news while there is still time to act on it. The ten tips below are written for the person who has been handed a software project alongside their normal job, often an operations director or IT manager, as much as for the full-time project manager.
Before the work starts
1. Get involved before the scope is fixed
The decisions that shape a project are made early, often in the conversations that lead up to a quotation. If you will be running the project, be in those conversations. You will hear what was promised, what was assumed and what was left vague, and you will not have to reconstruct it later from a proposal document.
2. Write down what success looks like
“A new stock system” is not an objective. “Warehouse staff can book in a delivery in under two minutes, and stock figures match the accounts at month end” is one. Agree a short list of measurable outcomes with the people paying for the project, and for each piece of work agree the checks that will show it is finished. The importance of acceptance criteria explains how to write those checks. When something unexpected comes up, the list is what you go back to.
3. Know who decides
Every project has several people with opinions and, if it is to succeed, one person who can say yes or no to a question about scope or priority. Find out who that is before the first difficult question arises. If the answer is “a committee”, ask for one named person who can decide between meetings.
It also helps to know how your supplier is organised. Scrum, for example, does not define a project manager: the Scrum Guide gives the Product Owner the say over what is built and in what order, the Scrum Master responsibility for how effectively the team works, and the Developers the plan for each Sprint. As the client’s project manager you will mostly deal with the Product Owner, or be asked to act as one.
While the work is under way
4. Keep a short risk list and read it every week
A risk is a problem that has not happened yet. Keep a list of the handful that matter, each with an owner and an action. On software projects the usual ones are the quality of the data to be migrated, access to a third-party system, the availability of key staff for testing and a dependency on one person’s knowledge. A long register that nobody reads is worse than five lines reviewed every Monday.
5. Ask to see working software
A report that says a feature is “80% complete” tells you very little. Ask to see it running, on a test system, with realistic data. Regular demonstrations are the most reliable measure of progress there is, and they catch misunderstandings while they are cheap to correct. If several weeks pass with nothing to show, treat that as a risk and raise it.
6. Control change without forbidding it
Requests for changes are a sign that people are paying attention. The mistake is to accept them informally. For each one, write down what is being asked, have its effect on cost and date assessed, and get a decision from the person identified in tip 3: add it, swap it for something of similar size, or defer it. On a fixed-price project this discipline is what keeps the price fixed.
7. Be the realistic one
Enthusiasm at the start of a project produces optimistic dates. Your job is to ask what the date depends on. If an estimate assumes that the client’s staff will test within two days of each release, say so and check that they can. When a date slips, re-plan openly and promptly. People forgive a delay they were told about a month ahead far more readily than one announced the week before.
8. Keep decisions moving
Developers waiting for an answer are either idle or guessing, and both cost money. Agree one channel for questions, answer them within a working day where you can, and chase the people in your organisation who owe a decision. Much of a project manager’s value on the client side is in removing these delays.
Going live and afterwards
9. Plan the go-live as carefully as the build
The end of the build is not the end of the project. Before the system goes live you need a rehearsed data migration, staff who have been shown the system, a way back if the launch goes wrong and somebody on hand to fix problems in the first weeks. Decide who will support the system afterwards and on what terms before launch day, not after it. Managing user expectations covers the part that involves the people who will use it.
10. Review the project and keep the records
Within a month of go-live, spend an hour with the team on what went well, what did not and what you would do differently. Write it down in a page. At the same time, make sure your organisation holds the source code, the documentation and the logins for every account the system depends on. A project that ends without those leaves you dependent on whoever built it.
A weekly check for the project manager
Tips are easy to agree with and easy to forget. These six questions, asked every week, cover most of them:
- What did I see working this week that I had not seen before?
- Which decisions are waiting, who owes them and since when?
- Has anything on the risk list changed?
- What changes were requested, and has each been assessed and decided?
- Is the next milestone date still realistic, and what does it depend on?
- Who needs to hear something from me that they will not enjoy hearing?
If you can answer all six without looking anything up, the project is under control. If you cannot answer the first, find out why before doing anything else.
If you have inherited a project that is already in trouble
Start with the same questions, then establish three facts: what has been built and can be shown working, what has been paid, and what remains of the original scope. Those tell you whether the project needs a firmer hand or a different plan. Our software project planning worksheet is a useful way to restate the scope, and where a project has stalled with a supplier, a project rescue assessment gives you an independent view of what exists and what it would take to finish.
If you are still at the planning stage, the best way to kick off a new software project covers the first meeting and the weeks around it.