How To Run Successful Software Projects

Learning to run projects is an essential skill for tech leads, managers and engineers,

Have you ever wondered what a Director of Engineering at a company like Oracle would say about delivering projects… successfully?

I am beyond excited to feature Owain Lewis to share his insights on running successful software projects.

Owain, is a Director of Engineering at Oracle, author of the Software Engineering Manager newsletter and creates incredible content on LinkedIn. You can join his free community for engineering leaders where you can get help and support.

Let’s do it, I’ll leave you in Owain’s capable hands.

---

Delivering projects is essential to your career, but managing projects well can be challenging.

A project may be defined differently depending on your organisation, but it should be a non-trivial work item with a clear start and end state. For example, a project might launch a new customer feature or migrate to a new database system.

As a tech lead, manager, and director of engineering, I’ve managed hundreds of projects of different sizes and scopes. In this article, I’ll share some secrets to managing large projects that will help you and your team deliver projects more effectively.

Whether you’re a manager or IC, project management is one of the most valuable skills you can develop. Your entire career will be spent working on and delivering projects.

It’s easy to underestimate how challenging project management can be. Large projects cost companies a vast amount in terms of cost and time. Large critical projects can also be visible to senior leadership, leading to pressure and scrutiny.

Without a doubt - the most stressful and challenging times in my career have been dealing with high-visibility projects (VP level) with fixed deadlines that were going off track.

Given you’ll spend most of your career working on or leading projects, it’s crucial to have a repeatable process for delivering projects on time with minimal stress.

So, how do you run projects well at scale?

Make Success A Repeatable Process

Because projects involve cost and complexity, it’s essential to have a standard and repeatable process in place to avoid mistakes, confusion, and wasted effort.

Although many people react negatively to the word process, managing projects at scale requires some standardisation. If you don’t have a repeatable algorithm for managing projects, the result will be wasted time and effort, mistakes, inconsistency, confusion, and frustration.

Large engineering organisations (Amazon, Oracle, Google) will run tens or hundreds of projects concurrently. At scale, consistency wins.

Thankfully, some easy steps can help you execute well every time. Lessons from larger companies can help smaller teams run better projects.

The Engineering Project Lifecycle

Here are the steps I follow to run engineering projects. Most software projects follow a standard lifecycle of planning, design, development and test, launch, and post-launch.

Agile approach

It’s important to point out that with agile projects, you may iterate quickly through these phases in a non-linear order. Sometimes, you skip certain phases entirely. That’s fine. This is just a guide to think about the different parts of the project lifecycle.

It’s worth being mindful that changing the scope, requirements, or design too often could signal a problem.

Phase 1: Planning

Before you start building anything, a team needs to understand the project goal, constraints, and requirements.

The goal of the planning phase is to

1. Get clear about what you’re building

2. Ensure everyone is aligned

3. Clarify high-level project milestones

Two documents you can use in this phase to plan are

1. Project Requirements Document (PRD)

2. Project Plan

A Project Requirements Document describes the customer requirements and scope of the project. A plan can be used to outline the high-level goal, roles and responsibilities, essential dates, and significant milestones for the project.

One potential mistake is thinking that project planning needs to be time-consuming or difficult. Using templates and keeping things simple, you can write a basic requirements document or plan in a few hours.

To close out the planning phase, schedule time to review the requirements and plan with the team and ensure everyone is aligned on the project's scope and goals.

Phase 2: Design

During the design phase, an engineering team will determine how to build the solution. During this part of the project, the team may work on proof of concepts, conduct research, and decide on technical architecture.

When appropriate, each project should have a technical design document describing the architectural approach and any technical considerations that need to be documented. A good design doc covers the high-level technical approach, design decisions, and trade-offs that were considered.

These documents should ideally be reviewed with the team to gather feedback on the technical approach and identify problem areas that may still need to be considered.

In larger companies, there may be a more formal process for reviewing technical designs with an architect or group of senior engineers.

These types of documents should be based on a standard template to ensure all the essential details are covered.

A good technical design doc:

• Helps early identification of design issues that would be expensive to fix later on

• May include diagrams to provide clarity

• Creates alignment on technical approach within the team

• Ensures fundamentals have been considered (metrics, design for operability)

• Serves as a reference for design decisions and tradeoffs considered

Phase 3: Construction And Testing

The construction phase is when you build and test your project. This is where the work happens.

Phase 4: Launch

Launch is when you ship your project to customers. For more complex projects, consider an early pre-launch phase to get feedback. This might be called a limited availability (LA) or beta launch.

Launching early to a subset of customers lets you get meaningful feedback and identify bugs or UX issues. For this reason, you may have seen tech companies offer waitlists or an alpha/beta version of their projects to early testers.

Where possible, getting early feedback on your project improves confidence and ensures that the project launch goes smoothly.

Phase 5: Post Launch

After launching your project, you may still need to do additional work, such as publishing promotional materials (e.g., blog posts) and completing any remaining technical cleanup work.

When a project ships, celebrate the launch with your team and reflect on how the project went and what could be improved next time. Completing a project is a great feeling, so enjoy it.

Bonus Tip #1: Documentation

Good project documentation is essential for building clarity and alignment within a team. For good reason, a culture of writing is found in many large tech companies, such as Google, Amazon, Microsoft, and Oracle.

Large software projects can be incredibly complex, and writing is the best way to share information and think clearly.

You can create templates for all the standard documents your projects require, such as a project plan, a technical design doc, and a product requirements doc.

Bonus Tip #2: Communication

An essential and underestimated part of running projects is good communication.

The most important lesson I learned about running projects that are visible to senior leaders (VP+) is “no surprises”.

The last thing you want to do is tell your senior leaders a week before launch that the project you’d been saying was on track for the last few months will be delayed by another month. Surprises reflect poorly on you and your team.

There’s no need to sugarcoat things. If a project is going off track or is at risk, it’s much better to call this out early and adjust timelines and plans.

Every team should have a way of providing regular updates on progress at a defined cadence. The person leading the project should give weekly updates.

A standard status update should cover

• If the project is on track or not

• Progress made against milestones

• What’s been done so far

• What’s left to do

• Any other callouts or risks to surface

Here is an example of how you might present a weekly status update:

Status: Green

Goal: Launch new user sign-up flow by 10/1

Summary: We are on track. The code is complete and ready to test. Last week, security approved the launch of the feature. We plan to finish testing by 9/15. 

Risks: None

Milestones:

- Planning (Done)
- Design (Done)
- Code complete (Done)
- Testing (In-Progress)
- GA - 10/1 (On-Track)

Summary

A reliable project management process is essential for any software team. Learning to run projects well is a valuable and essential skill for technical leaders (ICs and managers).

When running a project:

1. Get clear on the goal and scope before you start building

2. Use standard templates for project plans, product requirements, and technical design

3. Break large projects into manageable milestones

4. Remain agile but be wary of changing scope, requirements, or architecture too often.

5. Ensure there’s a single owner for each project

6. Create a technical design document to clarify the implementation

7. Communicate progress at a regular cadence with stakeholders

8. Finish projects by reflecting with your team on what went well and what could be improved next time.

A Thanks From Ryan to Owain

I just wanted to add a huge thanks to Owain for taking the time to collaborate with me on my newsletter. If you told me, 3 years ago, when I first started creating content, I would be working with people of Owain’s calibre, I would have been stoked.

Owain shares so many actionable tips and great templates that I have actually used since we started getting to know each other. Go and follow him:

On LinkedIn. Visit his website. Check him out on GitHub. Join his free community for tech leaders.

---

This newsletter recently hit 4,600 subscribers, that’s so wild. Please like this (click the heart button at the bottom) and subscribe. It keeps me motivated and gives me heaps of help.

Just quickly whilst I have you:

• Want to write a guest post for this newsletter, let me know!

• Check me out on LinkedIn. I’m at >52,000 followers now.

• Have a discount or deal that my paid subscribers would like? Let me know and I’ll add it to the paid subscribers-only area and you can get it in front of 1,000s of eyes.

• Interested in some form of sponsorship for this newsletter? Hit me up.