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.