A manager of managers.

I train managers on a daily basis. As the manager of 8 managers currently, I am noticing patterns in teaching the same fundamental principles that I have found, through my own experience as a technical project manager, to be helpful core skills. It seems appropriate to start writing down and sharing with my staff these principles in a series of guides. This will be the first of hopefully many writings that aim to help my own company members and anyone else looking to become a solid technical project manager.

What is a technical project manager?

It varies per organization, but in this article, I will speak only from the perspective of technical PMs in my company, Eagle Rocket LLC–a web development, web software, and cloud solution agency. The role of the technical project manager at Eagle Rocket LLC is complex and dynamic. It involves being a direct representative of the company to the client, or client’s stakeholders, and acting as a team-lead to our developers on the project. The PM’s job is to keep the client in the loop, informed, and satisfied. As well, they are responsible for scoping out the project, keeping it on budget, on time, and pushing the development team to complete the project. At this point, we should discuss the project management golden triangle, to which the previous sentence alludes.

The golden triangle of project management

There are three core considerations that every technical PM must be acutely aware of.

1) Scope – The width and depth of a project, expected and actual. 

2) Timeline – The duration and progress of the project, expected and actual.

3) Budget – The expected and actual cost of the project, both internally ‘in-house’ and to the client.

Scope

At Eagle Rocket LLC, technical project managers scope projects on a daily basis. Scoping a project is an art form that requires nuance and experience to do effectively. In this regard, our PMs act as both system analysts and investigative entities. The process goes best when it looks like this:

First, as a project becomes on our radar, the PM interviews the potential client or client’s stakeholder and begins initial discovery. Discovery should not just be a painless process for the client–it should be exciting and impressive. Good discovery could take the form of a phone call, a video meeting, or a series of emails. The technical PM doing discovery has goals, which are, in order of importance:

1) Give the client complete confidence that their project can and will be delivered if they work with our company.

2) Find out exactly what the client’s needs and problems are.

(Note: The client often does not know, in a technical sense, what they need or what their problems are. In these frequent cases, the technical PM needs to bridge the gap between non-technical venting from the client and technical diagnosis based on that non-technical information or pain points).

3) Create a broad technical plan based on the information gathered from the client of how Eagle Rocket LLC can develop a solution and value proposition that is affordable, effective, and desirable to the client.

4) Using our development team, create a formal, specific development roadmap that becomes the working scope of the project.

The scope should be organized and detailed. It may take the form of a spreadsheet, an outline, or a presentation–whatever is most effective for the client audience. Then, a budget and timeline need to be established before presenting to the client and closing the sale.

When a PM is managing a project, scope creep is a real danger. Scope creep is when a project grows in size after the formal scope has been defined, like a balloon being filled more and more past capacity. It happens typically for two reasons.

1) The client tries to add more deliverables to the project once it is already in progress. Often this can be avoided by a manager writing a tight, explicit scope at the project’s inception, which is understood clearly by the client and signed into contact.

2) The manager underestimates the work required to complete the project and writes a scope that does not account for essential parts of the project that are required in order to deliver on the client’s expectations for a final product. This can be tricky to avoid, as when creating a brand-new piece of software that has never been made before, there are going to be unknowns and guesses made when scoping. It is always best to spend a little more time with the developers working through possible scenarios and problems to avoid going into a project with a loose scope that doesn’t account for major pieces of a project that are necessary to the expected deliverables.

Budget

Pricing a project is a tricky business in the digital space. With the product being virtual, and prices of competitors being as across the board as a scatterplot, it can be hard to craft a budget that feels comfortable to the client while still generating fair revenue for the company–covering development, QA, management, and overhead costs. Those four costs are the main considerations for the project price in the webspace. With little to no ‘physical’ costs like building materials, the pure human output is the core expense on digital projects.

This can be used as a fulcrum for creating leverage when pricing projects. The man-hours to create the product are often the correct gauge to give a dollar amount to a project. However, some clients are better priced on a value-created basis, particularly in the eCommerce space where value is more easily measured than on the non-eCommerce web where value is less intrinsic and measurable.

Once a project is priced and sold, the PM is responsible for making sure development, management, and overhead costs stay below the allotted budget and that the company-defined profit margin is kept intact. In this way, the PM has to carefully consider costs in every decision made on the project. Budget and scope are interlinked in the golden triangle, just as scope and timeline, and timeline and budget. Generally speaking, the rules of the triangle are as follows:

Longer development timeline = larger budget

Urgent client timeline = larger budget

Shorter development timeline = smaller budget

Less urgent client timeline = smaller budget

Larger scope = larger budget

Smaller scope = smaller budget

Larger scope = longer timeline

Smaller scope = shorter timeline

See the triangle forming now?

To conclude the budget part of this guide, let’s consider the client and budget. At times, a project may require a scope-adjustment, either an extension or reduction–depending on new requirements injected into the project after it is running, or if new information about the necessary development path arises, such as a once 10-hour component changing to look like it will take 40 hours. In these cases, a scope extension is required, which is typically also a budget extension. These requests to the client should be initiated by a transparent conversation about why the budget needs to be increased, and then followed by a fair request for additional funding. If met with resistance, this can be a challenge.

As long as the information is true and fair, the client will often approve a budget-change request–unless, of course, the error in scoping or budget was clearly made by an error on the side of Eagle Rocket LLC, in which case, we often foot the bill for the increase in scope. This can be prevented by more thorough scoping and ‘baking in’ a slush amount for increased scope in the budget, like a $1,000 reserve for scope changes. That way the client isn’t totally taken aback when a scope change is required. Clear client expectations are always better than adjusted and muddy ones. Creating those expectations and giving them a price is something that comes with experience and is often deferred to upper-management, which is totally fine in the early stages of the manager’s training and growth. Always use your upper management resources in times of difficulty and challenge.

Timeline

The timeline of a project is somewhat easier of a concept than scope or budget. It is the duration of the project, expected and actual. The expected timeline should always be longer than the actual timeline, as this promotes over-delivery, which is the best way to score points with a client. A project delivered ahead of schedule, below the expected budget, and that includes a bonus feature or two will always, always create a happy (or even thrilled) client. And speaking from experience, happy clients refer other people to companies that make them happy. We want that company to be Eagle Rocket LLC. Show me a client that received over-delivery and was unhappy with it–they don’t exist.

Timelines are best created when a few considerations are in mind.

1) Client need — When does the client need or want the product?

2) Company resources – When can we deliver the project with the allocated budget and our development bandwidth?

If you refer back to the golden triangle equations in the ‘budget’ section, an expedited project will require more development costs. There is a happy medium that the PM must find between what we as a company can allocate to a project in the timeline and what the client expects or needs for the delivery date. Having more budget may help us ‘crash’ resources and expedite a project, but there is no substitute for time in development and testing no matter how many resources are on a project.

There is a dance that a PM must perform in pleasing the client with a timeline that will allow the scope to be delivered in the client’s target budget and desired delivery date. It is always better to underpromise and overdeliver rather than the opposite. Keep in mind a buffer for the timeline when creating one. Assume it will take longer than we expect and cost more. Tech projects almost always cost more and take longer than estimated, thus, reasonably padding budgets and timelines is a necessary practice in order to avoid messy client scenarios.

Again, real-world experience is the best tool for assigning a timeline to a project. Defer to upper managers for help and ask more senior PMs what they think. A 5-minute hot take from a 10 year PM can be more valuable than 5 hours of research and guessing by a junior PM. There is no shortcut to experience. Expect to make mistakes on early career projects that you lead. Take up a mindset of learning from mistakes and failures will turn into lessons. A necessary skill of a good PM is being able to recognize mistakes, owning up to them to the client and to one’s own manager, and course-correcting with grace and humility. Never, ever, try to hide a mistake internally–always notify a manager immediately. However, not all mistakes are necessarily relevant for the client to know about. A technical issue, for instance, that could be resolved internally and is not project-breaking should potentially not be told to the client if it is going to be fixed. The manager’s job is to keep the client happy, and no news is always better than bad news. Only notify a client of mistakes and fires happening inside a project if the results of these issues are relevant to the client. If a fire is put out and the client never feels any impact, that is not really the client’s business–it is, however, a valuable learning experience for all involved in the fire.

Sometimes the client should know about issues on a project, such as in cases where more budget or timeline adjustment is needed, or when a major scope change is required. Otherwise, the client should be kept happy and as ‘in the loop’ as the manager sees fit in order to ensure a happy client experience. This kind of finesse is honed through trial and error and experience and is a core principle of customer service in all industries.

Conclusion

Hopefully this broad overview of technical project management, specifically the ‘golden triangle’ will help budding PMs find their groove and identify areas of improvement. As a PM with over 100 successful projects under their belt, I have a little bit of experience with many of the issues, challenges, and rewards of being a technical project manager. I love the job of being a technical PM and think it is one of the more interesting and engaging roles in tech. I’ll leave you with this adage from a former mentor of mine.

The project manager gets all the credit and praise for a project, while the devs rarely get more than a pat on the back from a manager, let alone the client. Conversely, when a project goes wrong, it is the project manager that takes the heat, from both the client and their own managers. The PM is first on the chopping block, and first to get bonuses. What a harrowing and exciting role to be in, no?

Until next time, remember the triangle. And remember, there is no substitute for experience. Go out there and make mistakes!