Over the years I’ve worked with a lot of other IT project managers that never really understand the technical side of their project or product. Most didn’t even have a desire to do so! Coming from both a business and technical background, I’ve found that being a technical PM is a huge advantage, not only to me, but also to the greater project and the other members of my team.
In most organizations, a project manager is responsible for:
- Creating and maintaining a project plan with tasks and estimates
- Communicating with both IT and business stakeholders
- Risk management and escalation
- Managing scope
Yet how can a good project manager…
…verify whether a developer’s estimates are correct for a given task?
…create effective and meaningful status updates without knowing what’s going on with development and QA, and what are the major issues the development team is running into?
…take effective and meaningful meeting notes without understanding what is being talked about?
The benefits of being a technical project manager extend beyond the typical PM responsibilities and create a more well-rounded individual that can help a project in many different ways.
1. Better Estimates
Fact: Estimating is hard.
If you’re curious why software development projects are always running late, read this great article:
With software development, it’s easy to forget about things like environment downtime, requirements changes and organization red tape. When someone estimates it will take “1 hour” to develop a widget because “it’s a very simple [screen/component/function],” I can call B.S. knowing it’s going to take much longer than that. People often forget about unit testing, handling negative test cases, creating test data to validate, code merges, documentation, etc. Almost nothing takes 1 hour.
When doing the initial project planning, I think it’s important to work with the developers on the team to map out what the schedule will look like. I try to ask questions about how complex a task is from a technical perspective, what kind of potential road blocks may arise and how confident they are in the estimate. This not only helps during the initial planning phase, but also helps with load balancing and figuring out what areas of the project will need the most focus to stay on track.
2. Add Value to Other Parts of the Project
What are the typical ways for a project manager to add value to a project? Keeping the schedule on track, staying organized, reporting status, etc. But there are only so many status reports one can write. How can a project manager directly help drive the project forward in other ways?
Another great benefit to being a technical project manager is being able to help out where the project team needs it the most. Here are some ideas during the different application phases where a technical PM can be helpful:
- Requirements: take notes in meetings to capture requirements and help the BA turn those into documentation
- Design: ask good questions and sometimes make suggestions during design session that will hopefully generate more discussion and ideas from other team members
- Development: smoke testing the application before it gets to QA
- QA: help with defect triage and manage the relationship between development and QA
- Pilot: work with the application users and take notes on feedback items that can be brought back to the development team for fixes or enhancements
On my projects, I’ve done everything from flashing new OS builds onto mobile devices to suggesting branching strategies and testing applications during pilot with my business team partners. I will do anything I can to help the project and the rest of my team.
3. Be the Link Between Development and the Business
Perhaps the biggest advantage to being a technical project manager is having the ability to fill the communication gap between the development team and the business team. This can manifest itself in many ways:
- Describing how individual development components relate to the big picture for an organization
- Ensuring the business team understands why certain technical decisions were made along with the benefits and trade-offs
- Explaining to the business why a requirement may not be technologically feasible – but here are some alternatives
So now you’re convinced that you should become a technical project manager…but how?
1. Take Time to Understand Your Project/Product
Talk to the developers on your team about the software stack. What kind of database is being used, is the code native or cross-platform, is the application a thin client or thick client? (And if you’re not sure what those terms mean, go find out.) What are competitors doing with similar applications or devices, and can anything be learned from those?
Becoming a good technical PM also requires knowledge from the business side of the project to see how it relates to technology. Take a look at the requirements and talk to the BA on the project. Talk to the end user (not just the decision makers who draw up the requirements) and learn how the product is going to impact them. How did the requirements drive technology decisions?
In the end, a project manager is never going to understand the code as well as the developers or the software stack as well as the architect or the requirements as well as the business analyst – but a project manager can be well rounded in all facets of the project and have a high-level understanding of each area.
2. Learn to Code on Your Own
3. Build Something on Your Own
After you learn to code, the next step is to work on a side project towards a goal. Maybe it’s a website or an iPhone/Android application. Just make sure it’s something that you’re interested in so you enjoy working on it.
4. Share Your Code
My final suggestion is one that you probably will dismiss right now: get on github and share your code with developers. Even though it may be intimidating to have more experienced developers look at your code, their feedback is going to be even more valuable than the development work you’ve done on your own.
There are still questions over how technical an IT project manager should be? From my experience, I’ve found it to be invaluable and strive to become even more technical every day.
Note: this is a cross-post with the article I wrote on the BlueFletch blog.