You’ve just been given your first assignment of software project management. Now what?
Probably you have lots of experience writing code. Being a project manager is something new, though. Don’t panic. Breathe deeply, follow a step-by-step plan, and you can succeed. You have good people working with you. Just make it possible for them to do their best.
Step 1: Evaluate the situation
A lot depends on what you start with. Do you have a detailed spec with clear requirements? Or is the definition a work in progress? Look over the information you’re given. Discuss it with your manager. Find out what’s nailed down and what’s subject to change.
Here are some questions you’ll need answers to:
- What is the scope of the project?
- Who are the stakeholders? Will you be able to talk to them directly?
- What’s the budget? Is it negotiable?
- Who’s been assigned to your team? Do you get to pick people?
- Has a schedule been set? What is it? Is it feasible? (Hint: The answer to the last question is always “No.” You do the best you can.)
- What resources will you need? What is available?
Put together the best answers you can get. Try to get a sense of how much is subject to change. If some points stay unclear or the schedule is unrealistic, let your manager know about your concerns. Don’t grumble, but let them know what issues will need watching.
Step 2: Establish timeline, budget, and team
Next, figure out what you’ll need to get the project done. You’re competing with other projects, so you’ll never get everything you want. Prioritize your needs.
What people will you need? For how long? If the team’s already assigned, you might not have a choice. But if you have input and you know the developers, think about their strengths. Which ones work well together, and which tend to have conflicts? Which ones have the technical skills your project needs?
How many people will you need? Remember that a small team of good people will get the job done faster than a big, poorly coordinated one.
Talk with developers who have relevant expertise. Admit that this software project management stuff is new to you, and you can use their experience. Find out what they think the most challenging parts will be. Maybe they know a code library that will take weeks off the effort.
Talk with the stakeholders to make sure you understand what they want. Sometimes there are unstated needs that the spec glosses over.
Once you’ve got a good sense of what it will take, lay out a schedule. See if you want to go agile, do Kanban or Scrum. Then double it on general principles. You’ll get pushback, but nobody ever overestimates how long it will take to finish a software project. Negotiate for the best schedule you can get.
Step 3: Carry out the project
Now it’s time to get going. Assign people to tasks, and keep track of progress (use something like Jira). The requirements will change. Problems will arise. Be ready to deal with them.
Make sure the managers know how it’s coming. The sooner they learn of any issues, the easier it will be to resolve them. Stay in constant communication with your team so you know if they’re running into problems. Don’t hover over them, though.
Here are a few concerns that could affect a project:
- Changes in requirements. If a big feature is added, make it clear it’s going to affect the schedule. If the schedule is moved up, explain politely that you can’t work miracles.
- Changes in personnel. Your best developer might leave or be pulled onto a higher-priority project. Make sure you know enough about what everyone has done that it won’t kill progress.
- Slower progress than expected. This always happens on some parts of the project. Keep management informed (by using something like weekly release notes); it’s better than having to explain when the deadline comes around.
- Documentation requirements. Most developers hate documenting their work. Make sure it gets done. The tech writers and the maintenance team will need it.
Step 4: Handle evaluation and transition
Finally you can deliver the product. There will probably be changes required before it’s accepted, so don’t let your team go on vacation yet. Sometimes the “last little changes” can be as long as the whole project.
But if you and your team have done your jobs well, you’ll get to acceptance. Now it’s time to hand over the product and documentation to the support team. They’ll have questions for a while, so leave room for them in your schedule.
There will be an evaluation of your project. You may want to conduct your own with the developers. You’ll find out you made mistakes, some of them painful. So has every other project leader. Admit them. Learn from them so you can do a better job next time. If you delivered what was asked for, you did a good job.
May the source be with you
The first involvement in software project management as a leader is the hardest part. Nothing will go exactly as planned. Try to follow a systematic plan and keep regular communications, and your chances of success increase.
