Managing Software Engineering Projects
Managing Software Engineering Projects
How to execute projects as an engineering manager.
A consistent and reliable system for delivering projects is essential for your team's long-term success.
Some of the common reasons for projects going wrong I see are:
Unclear goal and success criteria = misalignment, confusion, and failure to achieve desired outcomes
No planning = missed deadlines and projects dragging on for too long
Unclear ownership = things drift, and no one being responsible results in chaos.
No estimation or milestones = missed deadlines, lack of clarity on progress
This guide outlines the lessons and patterns I’ve observed as a tech lead and a manager running successful projects at large tech companies.
Projects
In most engineering organisations, a project is a significant amount of work that achieves a specific goal, such as “launch a new feature” or “build a new component”. Some projects take weeks, but they often last months from start to finish.
Small projects may do fine with minimal process, but anything significant lasting more than a month deserves rigour. The more important, time-consuming, or visible the project, the more critical good project management skills are.
In big tech, projects are usually date-driven. This is because internal teams or customers may depend on engineering projects, and executives must manage headcount and budget investments. When there is an important deadline and visibility around a project from senior execs, paying close attention to avoid projects drifting off track is essential to your reputation as a manager.
In most big-tech companies, technical projects are run by engineers, usually tech leads. Sometimes, junior engineers lead projects to develop their abilities and skills. Engineering Managers typically play a supporting role in project delivery while maintaining accountability.
If you’re familiar with the RACI matrix, a typical engineering project looks something like this
Responsible = Tech lead
Accountable = Engineering Manager
Consulted = Product Manager
Informed = Executive leadership
Five Project Phases
The Project Management Institute (PMI) defines 5 phases of a successful project. Since this model aligns well with how I’ve seen successful projects run at big tech, we’ll use it as the structure for this guide with some minor modifications.
The five phases are:
Initiation - Clarifying the who, what, and why
Planning - Clarifying the how and when
Execution - Doing the work
Monitoring - Keeping track, communicating progress and making adjustments
Closure - Learning, celebrating success, communicating the outcome
Initiation
The most common reason for projects to fail is a lack of clarity and misalignment around the project fundamentals (what, why, and when). Often, these issues don’t appear until you’re nearing the end of a project when it’s too late.
The initiation phase is where you broadly define the goals and timeline of a project, understand who the stakeholders are, and, when necessary, get sign-off on the project.
Scope
Misalignment around project scope is one of the most common reasons projects fail. Project scope defines the boundaries of a project, including the goals, deadlines, and deliverables. You want to deliver enough to achieve your goals whilst avoiding overwork and delay.
It’s surprisingly common to see projects where the team doing the work lacked clarity on foundational questions like “Why is this project important?” or “Why do we need to be complete by March?”.
Project Kick-Off Meeting
The best way to avoid misalignment and misunderstandings is to start every project with a kick-off meeting. This meeting aims to get everyone involved in the project to agree on and understand the scope - what, why, how, and when.
When people have agreed on the project scope, ensure it’s written down to avoid scope creep later in the project lifecycle.
Questions to clarify in the kickoff:
What is the goal of the project?
Who is the project for? Who is the customer?
Who will lead the project?
Why now?
When does the project need to be completed?
Is the project deadline fixed or flexible?
How will you measure success?
What are the key deliverables?
Who needs to be informed about the progress of the project?
How will you communicate progress?
Planning
“Those who plan do better than those who do not plan, even though they rarely stick to their plan.” – Winston Churchill
Good planning can make or break any project. The three critical areas of project planning are design, estimation, and milestones.
The output of a project planning phase is a clear understanding of what work needs to be done to achieve the project's goals. This may include a UX and technical design, a set of milestones, and estimates for the work so that completion dates can be projected.
The most effective project planning technique is “working backwards.” In this technique, you start with your target end date in mind and work backwards to determine what needs to happen by when—“To hit our GA date; we need to be code complete by week 8.”
Design
The design phase aims to take a set of requirements and identify “how” you will implement them, typically by writing design docs and/or producing prototypes. This is a critical part of the process since it clarifies what needs to be done and speeds up the execution phase. The design phase is a chance to explore technical architecture decisions collaboratively.
On complex projects, skipping the design phase and going straight to coding can mean the difference between success and failure. The design phase will ensure the team is confident in their architecture and the user experience.
Without a design, your team may get lost, spend too much time working out what they need to do, and build the wrong thing.
Task Breakdown And Estimation
Task breakdown involves identifying the key tasks needed to complete a project. Estimates give a rough idea of how long each task will take. Both of these steps are necessary for any project.
Engineers should always estimate using whatever technique they are comfortable with (developer weeks, story points, T-shirt sizes). Estimates are *never* reliable, but they usually give a “good enough” sense of a project's size and duration.
Milestones
Breaking a project into discrete milestones (steps) can help signal key dates and events. Milestones are helpful because they show forward progress on long-running projects. Projects without milestones lose momentum as they can feel like a never-ending list of tasks.
Monitoring
While working on a project, you’ll need to review the progress regularly to ensure things are on track and to take action when they aren’t. Things will usually go wrong on any significant project because building software is complex and unpredictable. Are your milestones on track? Are there any unplanned risks? What do your stakeholders need to know? Are you still going to hit your predicted date? Will you miss the deadline?
Engineers are usually the best people to assess whether a project is on track, so set clear expectations with your tech leads about how you need to be kept informed and how you would like to review progress.
From experience, people are universally bad at clarifying project progress. If you ask, “Are we on track?” you’ll typically get vague and confusing answers. Milestones and specific questions can help immensely since they are easier to understand.
Compare these questions you might ask an engineer to understand a project status:
“Will we be code complete by next Friday?” (clear, binary)
“Is the project on track?” (vague, unbounded)
Closure
When you finally complete a project, there are a few things to consider. Communicate the project launch within your organisation, announce it to your customers, celebrate success, and reflect on what you learned.
As an Engineering Manager, you get to act as a marketing spokesperson for your team. If a project was important, call out the win to your senior leaders by email or announcement without your group acknowledging the people who did the work. This is a great chance to get recognition for your team, which helps with promotions and visibility.
Leaders love to see teams ship, and an announcement can bring positive attention to the team.
If the project was customer visible, let your customers know that new features or updates are available.
After your team completes a project, take some time to reflect on what you learned as a team. What went well? What did you learn? What delivery processes could you improve next time?
Summary
If you follow the steps in this guide, you can predictably and successfully manage projects of any complexity.
The 5 steps for managing successful projects are:
Initiate: Clarify what you’re building, why, and who is responsible.
Plan: Ensure you have a user-facing and technical design in place, a clear set of milestones, and estimates on the project timeline that you can share with leadership. Agree on the design before you start building. It’s very costly to do this later.
Execute: Do the work.
Monitor: Regularly review progress and make adjustments as needed. Continuously communicate risks, problems, and information about the project with your stakeholders. Don’t wait until a week before launch to tell your VP the project isn’t on track.
Close: Reflect on what went well and didn’t, celebrate success, and communicate the project launch internally and externally.
Get In Touch
I would love to hear from you! If you enjoy my writing and want to connect: