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.