Thursday, 2 February 2012

Road to Destination 4 - Becoming a Software Development Project Manager

Have you ever seen any successful Project Manager? (at least in your personal point of view)
OK ... so if you say a "Yes", have you seen many successful Project Managers? or how many successful ones in ... let's say "ten"?

You can just simply ignore my article if you answer a "Yes" with the first question and "more than three in ten" with the second.

1. Introduction

    Nowadays, there are many different names which are actually similar to Project Manager (PM) such as Product Development Manager, Engineering Manager, ODC Manager, ... I've had chances to work directly and indirectly with many PMs. But unfortunately, I don't see many of them really successful. By saying successful, I mean keeping all stakeholders happy.

Observing during many years, I see that there are two types of PM as below:

* Technical Project Manager
* Professional Project Manager

Let's take a look at some examples to see what they really are.

2. Case studies

    Case study 1: Hung, who is a PM, has a new project coming in. He works with client via many meetings to understand the user requirement. Then, he writes down the software requirement for complicated software features. For simpler features, he guides and assigns his team members to write.

    After having client's approval on the software requirement, Hung continues to draw the software architecture and guides his team to create the software detailed design. For most of features, he reviews the detailed design before assigning the coding tasks to his team.

    For complicated features, Hung often performs code review and for simpler ones he has other team members to review.

    Hung also involves in the testing phase and especially he also supports in performance testing.

    Case study 2: Son, who is a PM, has a new project coming in. He checks the Project Proposal and SOW to understand about the upcoming project and asks for a Technical Solution to join with him to have some early communication with the client Project Sponsor (who approves for the project budget) and client PM.

    After understanding project scope and the product to be built, Son starts planning for resources, training, communication, etc. He creates the official Project Charter document and organizes the project Kick-off meeting.

    By planning for resources and training, Son has suitable team members to take care of writing software requirement, creating software detailed design, coding and so on. He also has plan for reviewing, testing and UAT.

    During project life cycle, Son often has frequent meetings with project team and with client to review project status and discuss on risks and issues. He also monitors carefully about the effort which the project team has spent, the complete work which the team has done, the number of bugs which are found, etc.

    Son communicates with client on the UAT plan and controls his team to reach the UAT entry criteria as planned. Once the project reaches the UAT exit criteria, Son asks client for the Project Acceptance Agreement and performs project closure activities.

3. Two types of PM
    Above are examples of two typical PMs. I believe you can easily guess which one is talking about the Technical PM and which one is talking about the Professional PM. Normally, people move from software developer to a team leader and then to Technical Project Manager. Some other cases, people will move from a QC, a BA or other positions to a Professional Project Manager after being trained on project management methods. PMP or PRINCE2 are the current two well-known certificates for Professional PMs while Technical PMs only work basing on their expertise and experience.
    Each type of PMs has strength and weakness.

3.1 Technical Project Manager

Strength: Obviously, this PM can understand all activities of the projects in details so the projects which he/she manages often have very good technical solution and with very good quality.

This is suitable for small teams and small projects (<5 members, 3~5 months)
Weakness: This PM spends too much time on engineering tasks. He/she doesn't have time and attention for building team spirit. He/she also doesn't monitor risk. As the result, the team seems to work hard and late quite often. People will not be happy with him/her and with the company and will leave after a while.

This PM doesn't pay attention on how much actual effort the team has spent. As the result, the actual cost of the project could be double or triple in comparing with what client has paid.

This PM himself/herself becomes struggle with social activities when he/she almost has no time for any other activities of the company.

This PM is not suitable for big projects.
3.2 Professional Project Manager

Strength: Suitable for big projects.

The project is often completed on time and within budget.

Having time window for building strong team spirit which is good for project team and the company.

Having time window for social activities and other activities for growing the company.
Weakness: This PM monitors the project quality via people and numbers. He/she doesn't really have good sense of what is really happening technically. So, the project seems to have quality issues if he/she doesn't have adequate resource.

Always requires at least one experienced technical member.

Some companies may not have all kinds of specialized people like Business Analyst, Technical Architect, Quality Control, etc. This PM may not be suitable for this type of company.

Not everyone can apply the theory of Project Management into the real world.
3.3 Software Development Project Manager
    Oop, I've been talking about the two types of PM. So, why the third?
    We can summarize the two types of PM as the picture below.
Type of PM Size of project Building team spirit Growing company Cost&Time Quality Most happiest stakeholder Unhappy stakeholder 90% of time spent for PM's life
Technical PM Small Not really Not really Hardly on time. Over budget Often good Client Project team, PM's boss (financial perspective) Engineering tasks Difficult
Professional PM Big Good Good Often on time and within budget Sometimes NOT good Balanced Not really have Communication Easy

    Being a Technical PM is quite easier in term of career movement because it is not so much different with what people did before that. However, it is a long road to be a Professional PM as people will have to study a lot of things which they haven't done before yet.

    In my opinion, the ideal PM (the third type) should be a combination of these two types. No matter which road you have moved up to the role of PM, you need to study more the strength of the other road. A technical PM should start studying Project Management theories to apply. A Professional PM should get in touch with the team closely to study from them.

    To be honest, I do see many PMs who don't really belong to any types listed above. They're neither mature at technical nor knowledgeable in project management methodologies and this has caused the failure of many projects. Actually, they're all good and strong people and that is why they have been promoted to the position of PM. However, either the company or themselves don't have good investment of time and money for their professional development.

6. Conclusion
If you're about moving the path of Project Management, think carefully which path you will move on. If you've already been a PM, see where you are now and see if you need to fill any gap. As a conclusion, there are THREE types of PMs

* Technical Project Manager: still work pretty much with software engineering.
* Professional Project Manager: practitioner of Project Management theories.
* The ideal Project Manager: the combination of the two.


  1. This comment has been removed by the author.

  2. The PMP Certification establishes a common language among project managers and helps each other work within a common framework. Once you have the PMP, you need to consider how you're applying the processes, tools, and techniques to projects. I took a training course for my preparation in and got ready for the exam on day 5!

  3. First step first! Know what you hope to achieve. Set out your goals and then pursue. Once your group knows what to do, one should start the planning phase. Work about how the software will function and give a fair solution to the problem statement at hand. All this happens even before the code is written!
    visit this site

  4. Thanks anh. Good article at least for me now ;)