Stakeholders - There Are Many, Not Just Client

In Project Management, there are a lot of challenges which Project Managers (PMs) need to manage to keep their God (their client) happy. However, this shouldn't been thought in an extreme way. In reality, some PMs may get this wrong when they put client on the "VERY" top priority when dealing with issues happening during project life cycle.

Yes, client's happiness is always one of project goals. However, there're many other stakeholders, beside client, whose interest PMs also need to balance to make them happy. A project is considered to be successful, ideally, when all stakeholders are happy. A project in which only client is happy while other stakeholders are disappointed is considered as a failure.

1. Background
Let's take a look at PMBOK v4, Stakeholder Management.

"Stakeholders are persons or organizations (eg., customers, sponsors, the performing organization or the public), who are actively involved in the project or whose interests may be positively or negatively affected by the performance or completion of the project"

In reality, typical stakeholders in Software Development are described in the below diagram.

The terms used to name stakeholders are different organization per organization. The bigger the organization is, the clearer these stakeholders are defined. In small organizations, some of these stakeholders may be combined into one, Program Manager, Technical Manager and Resource Manager may be just one person. The Program Manager may be called Group Manager, Group Leader or Senior Manager, etc. and in general they are the ones whom PMs report to. QA/QC Manager, Technical Manager and Resource Manager are also called Functional Managers.

3. Case studies
3.1 Case study 1

Problems With strong technical background and many years of experience in software development, Lee had moved up to Project Manager position for a few years. Also, with excellent communication skill, Lee managed client's expectation very well. One day, Lee planned for a project to be finished in 4 months. During project execution, Lee received many requests from client, some of them were detailed requirements, the other were changes against the original requirements. To make client happy, Lee clarified the requests and was willing to support every single request from client. After two months, due to reworking for supporting changes and due to new requests coming in, Lee saw that he couldn't deliver the project in the 2 months left so he asked the team to work late. Lee also requested for additional team members to support. Consequently, during the last 2 months the team worked really hard and under a lot of pressure from Lee. Finally, the project was delivered on time and also at good quality. Client was happy. At the project post-moterm review, Lee's program manager told him that even he had managed to deliver project on time, the project couldn't considered as a success. Firstly, many team members had escalated to their line managers that they're unhappy with Lee, some of them even resigned from the company. Secondly, the effort was overrun more than 50%. Being disagree, Lee argued to the program manager. He said, after all client was happy with the project and it should be a successful project. Root cause analysis Lee is a particular example of Technical Project Manager. Under stakeholder management aspect, Lee managed well one key stakeholder which was the client. However, he didn't manage other key stakeholders which are project team members and the program manager.

3.1 Case study 2

Problems Nam was the Project Manager and he had started one ODC for nearly 6 months. During this time, client was impressed with Nam in communication and managing their expectation. He's often very clear and very sharp when resolving project issues. While Nam was always on time in supporting client requests, he often had problem with his program manager. He wasn't willing and proactive in giving report/information to the program manager. Project status reports were often late or forgotten, he only shared the information to the program manager when being asked. He was also very strict in adding people to the project. Many people who were proposed to his project were often rejected by him because they didn't have enough required technical skills. Furthermore, he was also not willing to collaborate with QA Manager to follow the working processes. As the result, the program manager didn't know whether Nam was doing a good job but he was even annoyed being escalated some issues which he was not reported upfront. At the project performance review, even Nam had done a good job in making client happy, he still didn't receive good compliment in the project and was asked to improve the way to work and support the program manager, the QA Manager and support to develop people in the company. Root cause analysis Like the first case study, Nam supported very well one key stakeholder which was the client. However, he didn't manage other key stakeholders who are the program manager, the QA Manager and the Resource Manager.

4. Typical Stakeholders and Their Expectation
Identifying all possible stakeholders together with their interest is the key point to succeed. In general, I list out here very typical stakeholders which PMs need to manage their expectation to make sure they are happy, hence the project becomes successful.

Stakeholder	Expectation
Client	The software package is delivered on time with good quality.
Program Manager	- The project is finished with good quality, on time and within budget. - The information/report are provided in time.
QA Manager	The project team follows the standard process The project team contributes to the process asset
Functional Managers	(QA/QC Manager, Technical Manager and Resource Manager) - Project team members are utilized well and have right assignments - Project team members are developed and grow in the project - Principles/policies are followed.
Sales team	Commitments made to client as stated in SOW/Contract are satisfied.
Project team	Good team spirit Right workload during project life cycle

5. Conclusion
Client happiness is always a clear goal in every project. However, beside client there are still other stakeholders who are also important to the project's success and so important to the reputation of PMs. A PM whom many people are concerned to work with couldn't be a good PM, a PM who only focuses on his own project and doesn't support to grow the organization couldn't be good neither, etc.

Software Testing – Where is next place?

Software Testing in VN has been growing rapidly in recent years. Ten years ago, when asked about Software Testing, most new IT graduates did not know exactly what it was, the career of their choice was only Software Development. Most testing certifications were not known.

However, all just changed - KMS Technology has recently celebrated a great milestone of achieving over 80% of testers certified ISTQB. I don’t talk about what value of this certification, the only having said that is how KMS Technology is aware of testing value.

 LogiGear and QASymphony have launched Test Architect (TA), qTrace & qTest and are in progress of commercializing their products. Other companies have dedicated testing services that they have not had it in their strategic plans before.

Most universities include testing major as an important subject of their training program. They are proactively cooperating with IT firms to build up the practical programs that adapt to the diverse needs of testing

1. Introduction
All are being transformed both quality and quantity as the nature of “All Models Are Wrong but Some Are Useful”

Those transformations are also posing challenges to engineers who commit to pursuing a SW testing career path. What will SW testing be in the coming years? What changes will be required to the skill set that testers should have? Especially, when Agile-based development is promoting its values in industry, the changes become stronger.

In this article, I would note personal opinions on the testing career path and thoughts of how testing may be reshaped in the future.

2. From transformation of traditional testing to Agile-based testing  

In traditional testing, testers often start their work in late phases of the process. They use specs, requirement documents … for designing test-cases. Any changes made to requirements cause many test-cases require updates. Therefore, if those documents are not stable, testers are better off waiting. Testers are keeping the primary role to confirm readiness of SW for release, testing responsibility is put on shoulder of the tester.

In contrast, Agile-based testing is a different story. It requires testers to participate during early phases of process. Light documentation is a principle of this testing (only high level test-cases or no test-cases needed) while automation is focused. Software testing is over comprehensive test documentation. In Agile-based testing, any change is welcome because very little effort is needed in updating documents. Testing responsibility is shared among everyone; SW is released when “DoD” (Definition of Done) is met.

3. To transformation of mindset and skill set of testing 

New trends in testing are asking test engineers have to “refresh” themselves from skills to mindset.

It’s time to change – the change of mindset to be more “agile”

Testing should be smarter by prioritizing what needs to be tested; what focused area of effort spent. An escaped may not be fixed immediately, it must be considered as a story which will be prioritized by product owner. The testing approach, then, is very important to gain the level of testing quality.
 

An approach I’ve recommended to my teams was to have a ‘to-do checklist’ and ‘item (or test cases) checklist’, that were used to replace traditional test-cases but did not take as much time for updates/ enhancements while still guaranteed level of testing coverage. The automation test is required in Agile model to serve regression testing.

Using the Agile model, testers may think of “playing” Software instead of trying to understand it. Because only when playing the software, testers won’t need a lot of documents to know what it is and why it has to be that; they have to proactively communicate with ‘the team’ (including both client and their team) instead. Their minds are not driven by any requirement documents that constrain their understanding about SW in only one way. In addition, they can quickly focus on changes of SW made that may be at risk of being wrong. However, it does not mean testing facets as principles; types and techniques ignored. Regression testing, for example, is still very important, which promotes the value of automation testing in the Agile model.

The changes stated in the table below are posing pictures of testers in new uniforms

4. From project-based testing services to OTC (Offshore Testing Center) and will be Testing by Work Order or Cloud-based testing?
In a project-based contract, the client doesn’t take care of the number of testing resources in the team, testing is under the plans of Project Manager, a tester may take assignments on multiple projects at a given time. Therefore, projects can use a diverse range of testing skills from organization. However, high pressure is put to testers in release periods. Soft skills are really not focused by mostly time of working with internal teams.

In OTC (Offshore Testing Center) contract, a dedicated testing team is built at the service provider site (usually offshore or near-shore) with agreed headcount. The team is responsible for all tasks assigned by the client. Offshore managers in this model are keeping roles of resource management & utilization and risks & issue management. While testers must own the techniques of both black-box and white-box testing, soft-skills (especially communication skill) are more focused by having more opportunities to directly work with the client.

I’m thinking of other forms of testing models that may be deployed in the future. When client don’t want to invest the time & cost of forming & training the testing team (OTC model) as well as not willing to have contracts in terms of project-based that take risk of losing Intellectual Property (IP) . The cloud-based applications with size small enough to not take a lot of time for testing or project domain is not too complicated to have specific training. Then, testing service providers may play the role of contractors for work order on demand. A work order can simple be a mutual agreement on completion of particular testing level (often being user acceptance test) for an application or a complex contract for the whole product. If this model is taken, testers may be required to own highly-skills on various testing types to quickly adapt to diversity of orders. Ability on quickly catching up changes of the technology and the most importance is to have high degree of tolerance under high pressure.

5. Conclusions
No matter what the testing is reshaped, the testers need refresh themselves. I don’t say that there is no room for Traditional Testing or Project-based or whatever, however making changes to mindset and skills will enable more opportunity in testing career. Where will you want to come? Is it time for you to gear up?

Modeling Projects - A Major Factor Determines Success or Failure

Understanding Sun Tzu’s Thirty-Six Stratagems wouldn’t make a good General of the Army. A good General must also know which Stratagem to be used when circumstances keep changing. Similarly, understanding the terminologies and models right in project management is quite important, but applying them right in reality will be more important. In particular, Agile software development model will work well in Time & Material contracts, but it will be a problem if being applied in Fixed Price contracts.

1. Introduction
I’ve heard many times people get confused when talking about the project types such as “it’s an ODC project”, “it’s a SCRUM project”, “it’s a Fixed Price project”, etc. While some of them are from PMI’s terminologies, some others are more about the software development models applied in projects.

So, via this article I am going to collect the concepts from the PMI standard (PMBOK v4) and from the real world of software development. Then, I’ll separate them into 3 groups of concerns: contract type, development model and business model. The reason for this step is that understanding these groups will help us to make the right combination from the beginning. Moreover, understanding which group of concern should be considered when things change will help us to make the right adjustment during the project execution. For example, a SCRUM project couldn’t be run under a fixed price contract or a project which has scope change frequently shouldn’t run under a waterfall model, etc.

In the background section below, I’ll use “buyer” to indicate the company who is looking for other companies to develop the software for them and “vendor” to indicate the software development company. Even I’ve tried my best to put here all types/models which I’ve ever worked/observed, there must be still some areas in which I haven’t touched yet so all comments/contributions are very much appreciated.

2. Background
2.1 Contract Types
If we are talking about the commercial aspect of the project such as how much vendor can bill buyer, we’re talking about the contract which bears the project. According to PMBOK 4th Edition, there are three contract types.

• Cost-reimbursable contract (CR): vendor pays salary full-time for project team members, vendor charges buyer full-time on them.

• Time & Material contract (T&M): vendor only charges buyer on the actual time which the project team members spend to work on the project.

• Fixed-price contract (FP): vendor commits one amount of money/effort and vendor charges buyer no more or no less when the project is finished. (Of-course this excludes change requests).

In reality, PMs often work under FP contract type but they’re not aware of (a serious unawareness). Even the official contract is a T&M or a CR, but if PMs make a commitment on a deadline with a given amount of effort, they’re actually running a FP sub-contract.

2.2 Development Model
If we are talking about which activities the project will perform, which development methodologies we will apply, we’re talking about the development models. Some typical Development models are:

• Full lifecycle (Waterfall or RUP): vendor performs all activities to build the software such as Requirement, Design, Coding, etc. and UAT support.

• Partial lifecycle: vendor just works on some activities like Testing, Coding, Bug Fixing, etc. Application Development, Application Testing, Application Maintenance, etc. are some more examples.

• Agile (SCRUM/XP/MSF…): buyer wants the vendor to build the software into short and fixed iterations.

2.3 Business Model
If we are talking about how client wants to work with the team, how client influences daily activities of the team via policies, environment, etc. we are talking about the business models. Some typical Business models which I’ve ever seen are:

• Pilot/Prototype/POC (Proof of Concept): vendor does some works in a short period of time from a few weeks to a few months. This is for both sides to get known each other before signing for a long engagement.

• Dedicated team: buyer wants to keep a team with specific names so that the knowledge is maintained.

• Fixed scope: buyer has an amount of work with a clear scope and they want to look for a vendor to implement regardless how the vendor manages it as long as they can deliver the software packages as committed. This is normally called Fixed Price model in duplication with Fixed price contract.

• Body shopping: buyer needs vendor to urgently provide some specific resources whom they couldn’t recruit at their end timely. These resources will work as if they are normal staffs at buyer’s side.

• ODC (Offshore Development Centre): Just like the dedicated team, but the size of the team is big and buyer aims to simulate their working environment at vendor’s side.

• OTC (Offshore Testing Centre): Just like ODC, but the work is mainly Testing.

• BOT (Build, Operate and Transfer): Like ODC, however, after a period of time, the team will be transferred permanently from vendor to buyer. The team becomes staffs of buyer.

3. Case studies
3.1 Case study 1

Problems Lee was appointed to be the Project Manager in an ODC and ran some small projects concurrently. In each project, client often worked with the team to have detailed requirements, estimated effort and duration before it was executed. Lee managed these projects from the requirement phase until the delivery phase. Every month, he collected and reported actual times for billing. After 6 months, client performed the checkpoint and realized that most of the projects were completed over budget even though all of them were delivered on time. The actual effort spent for each project was much more than the estimated effort, 100%, 200% and even more. When Lee’s manager asked him, he said “because this is ODC so I don’t control the effort of the team, I just manage to complete the projects on time”. As the result, client was unhappy with the team’s productivity and they felt their investment was ineffective. Root cause analysis Lee understood that he was running an ODC which was a business model. He’d been managing many projects from requirement phase to delivery phase. This was full lifecycle development model. However, he didn’t think about the contract type. For each project in the ODC, if he committed for an amount of effort to deliver the project that meant he was running a fixed price sub-project even though the official contract was T&M or whatever.

3.1 Case study 2

Problems Nam was the Project Manager for one new project and Rob was the project sponsor from client. Rob wanted the project to be run under SCRUM methodology because he didn’t have detailed requirements but a list of user stories (similar to list of functionalities but under end-user’s point of view).Nam and his manager discussed and proposed to client a dedicated team under a T&M contract. After 4 months, Nam and the team had completed many sprints and delivered many software packages to Rob’s team. However, the list which Rob assumed to be the scope had not finished yet, only 60/112 stories had been completed. Rob asked Nam for a finish date for all stories. After planning with the team, Nam committed the project to be complete in the next 4 months. Unfortunately, Nam couldn’t get it done after 4 months because sprint by sprint, there were so many changes happening. Rob was unhappy as he couldn’t have the software to go (Live) as his expectation. He raised escalation. Root cause analysis Nam and his manager were right to choose the contract type to be T&M and have a dedicated team. They were also right when agreeing with client on a SCRUM model. However, client had wrong expectation when they asked for completion date. There are two things to be considered here: • Understanding right SCRUM model: Rob shouldn’t expect a completion date of all requirements. Instead, he should have asked for what would be delivered in the next 4 months.  • Fixed Price contract can’t go with SCRUM model: when Rob asked for completing the list of remaining stories, Nam got back to him with a particular timeframe. Even there was no change on the contract officially, but with this commitment he actually made a fixed price sub-contract to Rob. How can a fixed price sub-contract be made on the scope which was unclear and kept changing when running under SCRUM model?

4. Making the right combination of models/types
I don’t intend to write this article to explain the terminologies but the main purpose is to give everyone a notice that the combination of contract types, development models and business models is very important in order to be successful. As you saw the two examples above, things looked right at the beginning but then silently changed and consequently, PM couldn’t holistically recognize and handle those changes.

The matrix below shows the all possible combinations according to my subjective judgment in the view of vendor. If you understand the models and know what you’re dealing with, a matrix like this may not be necessary.

5. Conclusion

Project modeling should be considered carefully at either pre-sale phase or initial phase. While most of mistakes in planning can be corrected, a wrong project model will be very difficult to fix. When modeling projects, there should be three groups of concern and the project managers or bid owner should be aware which concern they are dealing with. They are Project Types, Development Models and Business Models.

Doing Risk Management or Leaving Project Management

  Like magicians or fortune tellers, Project Managers (PMs) often deal with something intangible such as planning for future, forecasting, communication, etc. In these invisible stuffs, if PMs don’t do well one thing, the possibility of success will be very … very low. I want to say it is “Risk Management”

“All project management is risk management”
Eric Verzuh

1. Introduction
Many people who are doing project management don’t really do Risk Management. There are a couple of reasons such as they are not aware of it, they find it difficult to do, they don’t believe in it, and most importantly, they don’t understand it.

Not to cover all aspects of Risk Management, I write this article to put down some basic activities which people can start with Risk Management quickly.

2. Case study

Son was assigned to be the project manager (PM) for one software development project.  In this project, he took over one existing application and implemented a list of change requests. The project was estimated to be complete in 3 months with 3 developers, 1 BA and 1 tester. After transferring the existing application to the team, Son discovered a challenge which the team would be facing soon when they implemented the project. The challenge associated with a feature that imported data from a set of CSV files to the database. Son recognized that if data was stored in the CSV files incorrectly e.g wrong data types, wrong columns, etc. then the application would run unexpectedly. Moreover, he oversaw hundreds of cases having the similar situation as well. Therefore, he decided to add one risk into his list.

ID	Risk Description	Action	Priority
1	There are hundreds of cases which user can input data incorrectly to CSV files	To be review with the senior developer	2

After discussing with the senior developer, Son came up with a strategy of data validation and it would take 2 months to complete the full validation. Obviously, this work was not defined in the original change requests so Son decided to communicate to client. In addition, the senior developer also raised a concern. For importing data, the existing system was using a 3rd party data layer library (3PDLL) which the team had not worked with before yet. Son identified this as another risk and the risk list became:

ID	Risk Description	Action	Priority
1	There are hundreds of cases which user can input data incorrectly to CSV files	Inform client: this is out of scope and suggest adding it to backlog for future enhancement.	1
2	Data importing is implemented using 3PDLL, but the team doesn’t have experience on it.	Let the team do research on it and will revisit after one week	1

Son informed client about the 1st risk and the client was happy to accept it. After one week, the senior developer discovered another challenge regarding 3PDLL. The existing application had been using 3PDLL without manipulating Transaction and Error Handling. As a result, the application just stopped working without any notification when errors occurred. As this was the way the existing application did, Son decided to add it into the risk list in order to be improved and then communicated to client. The risk list became:

ID	Risk Description	Action	Priority
1	There are hundreds of cases which user can input data incorrectly to CSV files	Inform client: this is out of scope and suggest adding it to backlog for future enhancement. Client has accepted the data validation to be implemented in the future.	3
2	Data importing is implemented using 3PDLL, but the team doesn’t have experience on it.	Let the team do research on it and will revisit after one week	3
3	The current system is using 3PDLL without Transaction and Error Handling. They may cause strange behaviors when importing data.	Propose to client on applying Transaction and Error Handling to 3PDLL.	1

3. Let’s start doing Risk Management
According to PMBOK or CMMi Standard, PMs will need to plan for things like risk sources, risk categories, impacts, probabilities, etc. Risks should be analyzed qualitatively and quantitatively. Then, PMs should have strategies such as Mitigation, Avoid, Accept, Transfer etc to deal with the identified risks.

It sounds complicated, doesn’t it?

Now, let’s just ignore the above paragraph. All I want to say is that let’s start with a list and cover some regular activities as follows.
•    Identifying risks
•    Defining actions for risks
•    Monitoring risks regularly

3.1 Risk list
As seen in the case study, my list has four columns which are ID, Risk Description, Action and Priority. You may need more basic columns (or risk properties) like Status, Open Date, Owner, Closed Date etc. and advanced columns like Impact, Probability, Exposure, Source, Category, Strategy, etc. But I suggest that if you’ve never done with Risk Management before, you should start with a simple list first.

3.2 Identifying risk
I like one question of SCRUM daily meeting, “Do you have any obstacle?”. Keep asking this question weekly, daily, hourly, … or whenever possible will help to identify uncertain things which the team is facing. Risks come from uncertain things.

One important thing I want to mention here is that risks should be identified by every project team members. Keep asking and communicating with the team, PMs will see and find the risks which he can’t figure out by himself.

3.3 Defining actions for risks
Actions for risks must be as specific as possible. By answering the two questions below, you will find the corresponding actions.
1.    What can we do not to let the risk happen?
2.    What should we do if the risk happens?
The answers should not only come from PMs but also come from relevant project team members.

3.4 Monitoring risks regularly
Risks and actions must be revisited regularly, at least once a week. If you really do risk management (continuously looking for risks), there will be always many risks in your list. However, you only need to focus on the top prioritized risks.

4. Misthoughts about risk management
I used to think about risk management incorrectly, I also often see many PMs misunderstanding about risk management. So, I put here something called misthoughts.

My project has no risk: This PM doesn’t do risk management.

Risk management is complicated: It seems to be with huge projects like building an airport station, constructing a national park, etc. In software development, you can start with my simple steps and when you get familiar with it, you can do more.

I have no time to find risks: PM should encourage project team members to tell their concerns and worries about their tasks and project. Risks are principally identified from that.

My company doesn’t require me to do risk management: what do you think?

5. Conclusion

Not many people are convinced about the value of risk management until they’re facing with problems in project management and then they wish they should have done something early.

The risks and the corresponding actions which I presented in the case study looks quite obvious. However, I’ve changed it a bit when writing this article. In reality, risks were not managed and the team spent too much time on fixing defects caused by CSV files and 3PDLL. When these two issues were discovered, client accepted these two issues to be out of scope and can be considered in the future. Even of that, the project was delayed three weeks and effort was over budget nearly 50%.

I would say that you pay one cent for risk management not to lose a hundred dollars or more later.

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.