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.