Agile in Fixed Price Fixed Scope projects - Hybrid Contracts

It is well known that the traditional methods are not yielding to a better success rate of a project and thus there is a tendency to lean on Agile Methodologies. At the same time, clients feel secure with Fixed Price and Fixed Scope project as their financial outlay is limited and there is no ambiguity. What they miss however in this process is the value delivery. The traditional project management methodologies focus on the Scope, Time and Resources where all three are constraints. Ideally the focus should be on the Value and Quality delivered, given the constraints there by guaranteeing a better success rate of the project.

The software vendors are doing business and they work to earn profits. As such, with Fixed Price projects, the vendors tend to limit their efforts to deliver the agreed scope. With the pace at which changes are happening around any business, freezing scope for a project early on is nearly impossible as software delivered to such scope frozen early on is often less usable. With change is the key driver in optimizing the value delivery, clients and vendors have conflicting views on the change.

Agile methodology has evolved over these years and offers a solution to the problem of optimized value delivery. However, clients still feel that Agile approach does not secure their interests in terms of a definite price and time. Of course, their concern is genuine as they cannot afford to sign a project contract where the cost and time are elastic. While the basic premise of Agile is to embrace the changes, to succeed, it depends on a very high level of trust between the vendors and the clients, where both should work for a common goal and the contract should be profitable to both.

Having said that the Fixed Price (FP) Fixed Scope (FS) contracts offer very limited opportunity for vendors to practice Agile methodology. Making either FP or FS elastic will give some room for practicing Agile methodology. Let us explore how this can be accomplished in the contracts. Both the above contracting models requires a high level of trust between both the vendors and the clients.

Fixed Price Elastic Scope (FPES) contract: In this model, while the price is fixed, the scope can be variable. This model can practice a hybrid Agile approach, the scope is broken down to features and the development happens feature by feature. Depending the time taken to implement a feature, more features are added or removed. For instance, if a feature estimated to take 30 days is implemented in 20 days, one or more new features can be added to fill the time saved. Similarly if the implementation takes 45 days, then one or more features will be removed.

To bring in incentive for both vendors and clients, a discount factor can be agreed upon, which is applied while adding or removing features. For instance, in a case where the vendor has saved 10 days for a feature, the client instead of adding a feature that needs 10 days to fill the gap, will only add a feature with 5 days of effort, where the discount factor would be 50%. The same discount factor is applied on the converse (where implementation exceeds the planned effort).

Elastic Price Fixed Scope (EPFS) contract: In this model, the Scope is fixed, but the pricing is variable. The idea behind this approach to is arrive at a base rate and a profit factor. While the base rate and the profit factor, along with the generic terms and conditions are covered in the Master Services Agreement, the actual project scope can be covered in multiple Statement of Works (SoW). Requirement elicitation and scoping can be the first SoW. This way, the project can be split into smaller working software modules and the work items can be scoped in stages / phases. This approach will help the clients in handling changes with ease.

Here again, an approach like 60:40:20 can be adopted to prioritize the work items. This approach requires the work items to be grouped into Must have features, Good to have features and Fixes. Every SoW can comprise of 60% of Must Haves, 40% of Good to haves and 20% of fixes emerged out of previous deliveries.

The incentives for both vendors and clients can be based on categorization of the work items as New feature, Clarification, Fixes. New features are the scope items as elaborated during elicitation. Clarifications are such items that emerge out of elicited requirements during the design or build phase. Fixes are incorrect implementations by the vendors, basically design and build defects. Costs for each SoW can be computed by applying the profit factor on the base rate. For instance, the New features will be charged at base rate + profit, clarifications will be charged at base rate and fixes will be charged at base rate - profit.

With the above, we are not concluding that Agile cannot be practiced in an FPFS project. There are still ways and means that a hybrid agile approach can be thought of and practiced so that value delivery is the primary focus for all the parties. Do share your thoughts in the form of comments on the subject, and I will cover those in my next blog.

Why Software Product Delivey is not Identical to a Car Delivery?

I happened to sit in one of the project review meeting where client raised a question on software delivery expecting it to be used in production on the day of delivery by the vendor. He went ahead and started comparing it with a use case of a customer driving off a car upon taking delivery. I know all the project managers out there will jump in to say that don't compare apple with orange. On the one hand, yes, software development is unique and cannot be compared with production of a tangible product. On the other hand, attempts are being made by various standards organizations in helping the industry achieve a high maturity process capability and thus deliver production quality software consistently.

Software product vendors selling or licensing software products can however be compared to Car manufacturers. Take for example, Microsoft Office product suite, one can just go and buy it off the shelf and use it, just like driving off a car. This is possible for product vendors because, the product vendors over a period acquire enormous amount of knowledge on the targeted product domain and in turn subjecting it through as many cycles of testing before announcing its readiness.

A typical car from concept to production may take atleast few years and it would be in the order of around 3 to 6 years. During this period, the product undergoes various cycles of tests, which include crash test, drivability on the road conditions of the target market, etc. Similarly, software product vendors do conceptualize the product idea and then work on it over a period. The vendors are attempting to achieve a faster time to market, but by adopting newer product development methodologies. The one that works best is to identify the smallest piece of the software that can meet certain specific use cases and then build on top of it over a period of time.

In case of a software product, it is the vendor's responsibility to subject the product through various tests in production like environments before getting it out to customers. The tests include alpha and beta tests, where in interested end users are engaged to use it in production environments and collect the feedback on various aspects and the developers working on it to have all those critical issues addressed. Achieving a zero defect state may not be a possibility and vendors take balanced approach as to whether wait until all the identified issues be addressed or reach out to the market with certain known issues, which can be addressed in subsequent product releases.

But it is a different approach when it comes to bespoken software projects. The major challenges with the bespoken software projects that differentiates from software products include:

1. It is the Client who specifies the requirement. Though the vendor might facilitate documenting the requirements, it is the customer who formally agrees as to what need to be produced.
2. Lack of understanding and agreement on the non functional requirements, which are not documented in most cases.
3. The vendor might not be an expert in the target domain area. Though the vendor has expertise in the domain area, it is the customer's need that is final and not the vendor's understanding of the requirement.
4. The ever changing requirements. By the time, the vendor delivers the software, the requirements as agreed by the client would have undergone change due to various reasons.
5. It is difficult to unambiguously understand the requirements as the project progresses through various phases involving humans with varying abilities.
6. There are dependencies with various pre-existing or emerging software and hardware environments in the production environments of the client.
7. The client has the roles and responsibility to assume to make the project successful. However, it is for the vendor to ensure that the client understands their role and responsibility throughout project life cycle.

Another point to consider for this discussion is what constitutes delivery. A well written SoW (Statement of Work) clearly lists down the acceptance criteria, which when met would constitute acceptance of the delivery by the client. For a given requirements, no two vendors would build an identical solution. That's due to the tools, technologies out there for use and the varying intellectual abilities of those involved in building the software. It is important as to what the client wants, than how the vendor delivers the solution. For this reason, the client shall assume the responsibility of performing an user acceptance tests. Some times, the delivery of a software might mean implementation in production environment, which might involve data migration, appropriately configuring various pre-existing software and / or hardware.

In the end, it is all about managing the expectations of the client. It is not just setting at the start, but needs to be appropriately managed throughout the project life cycle.

PPM - Project Categorization

PPM is about ‘doing the right things right’ where things refer to work efforts, projects and programs, doing the right things refer to prioritizing and selecting projects and programs in line with the strategy & objectives of the organization and doing things right refers to execution of projects and programs in such a way the benefits are realized.

Portfolios, programs and projects are all formal expressions of resource assignment decisions. Accordingly, a systematic approach to collecting, selecting, planning and managing them is key to a high-quality Governance process. Projects, programs and portfolios share a common life cycle formed around four key stage gates, which are Create, Select, Plan and Manage. In the context of portfolio, an important and first task is to determine the investment types or categories with which the project or program are categorized. The purpose of this blog is to examine the need and methods of project categorization.

Purpose of Categorization

Broadly, the following are the purposes for which organizations find categorization useful.

Strategic alignment: Certain projects share common characteristics that will mean a common approach with respect to prioritization, project tracking and monitoring, strategic visibility, etc. Appropriate categorization of projects would offer better visibility in terms of strategy execution and benefits realization.

Capability specialization: Another reason, organizations would be interested in categorizing projects is to identify and group similar projects, so that they all share common tools, technology and terminologies, which will help better management of resources and communication across projects.

Promote project approach: Though this purpose is of minor nature, it helps organization to promote the project culture and differentiate operations from projects and also to use a common methodology to manage such projects

The following table presents a mind map of organizational purposes around categorization:

Primary Purpose	Sub Purpose	Benefits
Strategic Alignment	Selecting / prioritizing or projects / programs	Alignment commitments with capabilities
		Managing Risk / controlling exposure
		Allocating budget
		Balancing portfolio
		Identifying approval process
	Planning, Tracking adn Reporting of	Resource usage
		Performance, Results, Value
		Investments
		Comparability across projects, divisions, organizations
	Creating strategic visibility	Visibility across projects, divisions, organizations
Capability Specialization	Capability Alignment	Choosing Risk Mitigation Strategy
		Choosing Contract Type
		Choosing Project Organization Structure
		Choosing Methods and Tools
		Matching of Skill sets to Projects
		Allocating Project to Organizational unit
		Setting Price
		Enhancing Credibility with Clients
	Capability Development	Developing Methods and Tools
		Managing Knowledge
		Developing Human Resources
		Adapting to Market / Customer / Client
Promoting a Project Approach	Providing a Common Language	Facilitate better Communication
	Distinguishing Projects from Operations	To Better Manage the Work Efforts

Categorization Schemes

None of the standards or frameworks specify a particular scheme with which to categorize and it is left to the organizations to decide on the scheme that best suit their needs. It has been found that most of the organizations use a multi-dimensional composite attribute based categorization schemes.

Here again the following three broad approaches are in wide use:

Hierarchical scheme: In this scheme, projects are hierarchically grouped based on multiple attributes. For instance, at the top level, the projects may be categorized as small , medium and large, based on the estimated investments and then further categorized into the application areas like, Infrastructure, Enterprise Applications, Field Applications, etc. There could be further categorizations as well. Under this scheme, each project falls under one unique category under each level.

Parallel scheme: Unlike in the hierarchical scheme, in this case, projects are assigned several sets of attributes. For instance, the projects may be categorized by complexity, technology and strategic importance and a project may find a place in all three categories.

Composite scheme: In this scheme, the categories are determined based on the result of applying more than one attribute. For instance, the category project management complexity may be determined by combining multiple attributes like team size, number of units or modules to be delivered, development efforts, duration, etc. Similarly a category deployment complexity may be based on attributes like process impact, end user scope of impact, project profile, project motivation, etc.

Conclusion

There is no single scheme or approach that best suits an organization. It is for the people involved in the IT / Business Governance to carefully choose the categorization based on the organization’s Vision and Strategy and then create a process to consistently determine the appropriate category for a project so that the relevant strategic and tactical tools and methodologies can be applied to that project as well, which in turn will ensure realization of the intended benefits with a desired level of efficiency and effectiveness.

References:

Aligning Capability with Strategy: Categorizing to do the Right Projects and do them Right

Project Portfolio Management: Doing the Right Things Right

---

Leveraging Lessons Learned

Success = failure + failure + failure … Sounds familiar?

Leadership experts and management gurus have said enough about how failures lead to success. That is very true for the individuals when the respective person takes it in the right context and work on the causes of the failure to overcome it in the next opportunity. But how does this work in reality for the organization?

 

If you have been part of a project, which has failed to deliver the promised features on time or at the agreed cost, you are most likely out of that organization, as the management want to penalize those involved in it. In the process, the organization loses as it did not want to capitalize on the lessons learned by the team through the failed project and the new team that takes over might commit same or even different mistakes, which could again lead to failure. 

 

Agile projects are likely to fare better in this space as Agile project management calls for identifying things that went well and those did not went well at the end of every sprints. Here again the one question that remains to be answered is, how does the scrum master and the teams deal with the things that did not went well in the earlier sprint. Yet another question that needs to be answered is how open are the project team members in openly admitting their own errors and omissions, which could have adversely impacted the project. 

 

 

As far as the development teams, there are so much to be learnt on a daily basis, for example, the defects uncovered in unit testing, findings in the requirements, design and code reviews and even the project issues could lead to a great lesson to be learned by every other member of the team. 

 

 

Here are few ideas that will help the organization in leveraging the lessons learned by the teams through various errors, mistakes and omissions.

 

• Mentor the teams to the effect that they demonstrate accountability and responsibility and that admitting a mistake early on is a good thing. The earlier, the triggers are known, it is better as other members of the team would stay away from committing the same mistakes.
• Coach the teams to share, share and share with their peers and even across the teams. This can be accomplished by removing the mind blocks within the employees in admitting their own mistakes and they should be encouraged to share those for the good of themselves and the organization. It is the tendency of the employees that when they uncover any issues during unit testing and reviews, they would just fix it themselves and do not report it further.
• Encourage teams to share their previous experiences every now and then and for sure there will be some takeaways from such experiences for some members of the team.
• Bring in a culture within the organization which will discourage egos and emotions which are found to be the barriers for sharing.
• Promote risk management and encourage every employee to participate in it. It is needless to say that every identified risk has the potential of becoming an issue and soon can come in way to prevent the project from being successful. Past experience and lessons learned is a great source of risk identification.
• Above all, make the sharing the lessons easy by putting in place an appropriate knowledge base platform and train and encourage employees to use it.

 

Though the above ideas are more suitable for IT services organization, they can be practiced in any other organization as well with some tweaks.

 

Here is an interesting article to read on, where in Ken Bruss discusses about leveraging lessons learned for competitive advantage.

Key risk areas that can impact the project success

Till recently and to some extent, even now, some of us don’t want our insurance advisor talk about our own risk of life. It has been the belief for some not to think or talk about the risk of losing life. However, things are changing and most of us today are managing personal risks well by atleast transferring the risk to the insurer for financial protection. Risk management is not just financial protection and there is more to it, even though finance makes the core part in most cases. The same way, if we look at managing software projects, the project manager and sponsors had to deal with so many issues every now and then, before it was felt that preventing such issues coming along the way is better than dealing with such issues, which is what is risk management.

The risk managers or risk experts always think of a what if scenario for every action / decision so that all possible risks are identified early on and this in the past was thought to be creating ‘negative vibes’ and did not receive much support from the project sponsors. Because, when much of the risks are identified upfront, it might be so that the project may have to be shelved at the start itself. Here again, things have changed and most CxOs are accepting ‘failing fast’ a better option than failing at the end. Failing at start is an even better option. Refer my own blog on ‘failing at start’.

Given that most of the project sponsors and project managers have realized that risk management is better than its only alternative crisis management and are believing that risk management is a key area of project management, let us explore the key risk areas in a broader context that need a close watch which if not could impact the success of an end to end software project.

User Expectations

Even though a well written functional specifications exist, and the development team developing to that requirement, there is a potential risk of end users when they look at the final product go back and say that “this is not working in a way we want’, and pushing back the product for rework. This is mainly due to the fact that everything around the business is changing with time. The more time the development team take in involving the end users, the chances are very much likely that the expectation would have changed. Agile is the solution to address this risk area, where by the end users are participating in the development and small chunks of the product are delivered every now and then for user feedback.

There are more to it, most projects do not have the non functional requirements documented and much of the user expectations go around such software capabilities, for instance application performance is a key non functional requirement, which the development team is expected to take care of as part of. While the solution for this lies with the solution architect, the project manager and the stakeholders should not lose sight of this important area and should be managing the user expectations all through the project execution.

If one can identify or spot the potential risks around the user expectation and manage it well, the chances of the project successfully reaching the milestone is very high.

Technology Shocks

This is a broader risk area and could be broken down into many sub areas. Many projects hit a road block when it get closer to production deployment, by when the infrastructure team may find heavy investment in terms of hardware and software tools required to support the product in production. Some projects even faces issues in the early stages as well, as the development team may find some tools or technology not suitable for the given solution.

A well done pre-project risk assessment can help address this risk as the architects involves in such assessments can anticipate and call out such road blocks, which might help the project sponsors to take a call. Development teams in most cases would want to jump on to the project and start building everything themselves without considering re-usable off the shelf components being available for most capabilities. This tendency can add to the schedule risk, as the project may take longer due to technical issues that the team may face.

Managing risks in this area early on is very important as certain choices might be very difficult to reverse in the middle of the project. It could also be a case where implementing certain requirements with a given technology platform or tools could be much more complex than with certain other tools. Much of this responsibility lies with the Architects, who should do a good job to take the project pass through this risk area.

Skill gaps

While this item is to some extent related to technology shock, there is more to skill than the technology itself and that made me to call this out as a separate risk area itself. Soft skills play a key role in taking the project on the success path. Staff attrition is inevitable in software projects and as such managing the dependency on people is very important. The resources holding key roles should have the right attitude of hand holding the teams, willing to share the knowledge, quick and effective in on-boarding new members to the team.

Such skills of key resources holding the lead role even influence staff leaving the team or even the organization and it could be some of the best resources of the project team exiting for such reasons. The Project Sponsors should play an important role here in getting to know of such risk items and manage them well so as to keep the morale of the team high and get the best of the team.

Every member of the project should contribute towards the success of the project, keeping in mind the project goals and objectives. It is not uncommon that some key members of the project make certain decisions in such a way that is beneficial to him or them and in turn putting the success of the project at risk. This is a sort of political behaviour by some members within the project. Here again, the sponsors should involve more into the project and look for such risks spotted early on, so that control measures can be put in place by changing the team composition or by imparting necessary training or counselling to the needy members.

This third risk, when identified and managed well will ensure the team members collaborate and communicate well and deliver their best which eventually will contribute towards project success.

Lack of Risk awareness

Finally, lack of risk awareness by the project stakeholders is the biggest risk. This calls for a proper risk strategy and objectives at the organization level and at every project level and letting every member of the project to actively participate in risk identification and management.

While most project managers do mandate risk management as part of the project charter and do maintain a risk register, they fail to apply the risk management principles consistently, which eventually lead to incorrect risk prioritization. Not to be stressed, the controls and tasks identified to reduce the risk level also need to be monitored on par with other project tasks for timely actions. It is also a common mistake that the project managers do by missing out to estimate the efforts for risk management and not making it part of the project schedule.

Another important aspect of risk management, which is normally ignored is the communication and continuous monitoring. Risks need continuous monitoring and need different levels of communication or escalation depending on the risk level. Most projects have a stale risk register, where the risks are just identified and no monitoring or follow ups being done on them. Use of an appropriate risk management tool is recommended as it will ensure the visibility of the risks to all concerned with automatic alerts and escalations and also will facilitate consolidation of risks across multiple projects, there by facilitating managing risks at enterprise level.

Pre-project Reviews help projects fail at start

A new project was approved and a 15 member team sit round the table in the project kick off meeting with excitement and enthusiasm. Business Analysts have put together the stories which Developers have started developing. There were periodical project status reviews and there were issues and risks discussed in these meetings and the project manager did well in managing the issues and risks. There comes a message from stakeholders that all work on the project be stopped with immediate effect.

That may be sounding familiar to every IT familiar as study says that 37% of the IT projects are at the risk of failing. Another study finds that 31% of the projects are cancelled before even hitting the finish line.  It really hurts the project team members when a project is cancelled or shelved. But there could be reasons for doing so and such decisions are taken when continuing with the project will only increase the loss and would not bring in value for the sponsors. This is where ‘fail fast’ will help as some times pulling the project down even earlier would save a lot of efforts and money for the sponsors.

Let us see what can be done even before starting any work on a project, so that the potential failure is spotted in the pre-project stage itself so that the project is not allowed to start in the first place. When the need for a project is felt, the executive management (sometimes called Project Review Board) takes a look at it and reviews it and if it sees merit in it, gives a go for the project. In some cases, by the time the Project Review Board (PRB) sees the project proposal, considerable efforts would have already incurred in the form of requirement gathering and analysis. The review by the PRB members, when done well will bring out the ability to measure the risk exposure and the RoI (Return on Investment) of the project, which in turn influences the further decision. However, it is important here that the PRB members shall be presented with adequate information that helps taking the right decision. A well drafted checklist or template that captures all the required information would help not to miss out the details and will help reduce the projects failing down the road.

The project proposal template shall at a minimum capture the following details, so that an informed decision is taken by the PRB.

Motivation:

The problem the project is expected to solve or a business opportunity that the project will help the business to capitalize should be stated well, so that the PRB members are able to appreciate the motivation behind the project need. It would be appropriate to quantify the value / benefit the solution would bring when implemented as intended. Some projects may bring immediate benefits, whereas some may bring benefits in the longer term, in which case, the same shall be called out explicitly. Similarly some projects may bring in monetary benefits, while others may bring in intangible value / benefits.

Estimated investment:

It may not make sense if the investment to be made for the project is significantly higher, which may leave the value or benefit negligible. Most projects get hit on account of cost overrun. The estimate should be close to being accurate and use of a template will make sure that all cost elements are considered. In some cases, a better estimation can be made only after gathering requirements with sufficient details. It would be wise that in such cases, the PRB may take a call to sponsor the initial efforts alone and let the proposal be placed again for review with more accurate estimation.

Constraints:

All projects will be constrained with various ifs and buts. Each possible constraint should be identified and called out in the proposal document. Each constraint will have one more associated risk items for which a contingency plan and mitigation plan has to be put in place. Risk Management practice has evolved in recent times and there are methods and techniques with which the risks can be quantified (a factor of probability and impact) and the overall risk exposure of the proposed project can be measured. This will help the reviewers to take an informed decision whether this much risk is worth to be taken for the value this project might give back.

Solution longevity and re-usability:

It would help if the expected life of the solution is determined. Some of the solutions may have shorter life, but may offer the re-usability with minor changes / enhancements. This will have to be determined considering the longevity of the tools and technology that forms part of the solution. Considerable number projects get cancelled as the sponsors gets to know that the useful life of the solution is going to be short and that the project may not be completed on time leading to further reduction in the longevity.

The above are some of the key factors that influence the decision on the project. There are many other factors which depending on the nature and size of the project may have significant influence on the decision making. For instance, security and compliance requirements could be a significant risk, which the PRB needs to know of while taking the go decisions on projects. Other factors that may find a place in the Proposal document include, deployment infrastructure, post production maintenance aspects, choice of technology, resource availability, etc.

On top of everything, the team that prepares the project proposal document should have the expertise in the business domain, technology used, estimation and related skill areas. Typically this will require a team of architects of appropriate specialization to accomplish this.

References:

http://www.zdnet.com/blog/projectfailures/cio-analysis-why-37-percent-of-projects-fail/12565

http://www.it-cortex.com/Stat_Failure_Cause.htm

http://www.articlesbase.com/training-articles/project-failure-what-are-the-reasons-for-and-statistics-on-it-871395.html