Agile Project Management: Budgets and Contracts

Citation preview

www.data-solutions.ch

Content 1. What is this book about? 2. Why agile budgets and contracts? 3. Agile budgeting 3.1 Why do we need a budget? 3.2 Why are budgets a problem? 3.3 Who is creating and managing the budget? 3.4 Cost per iteration, per team? 3.5 How many iterations per team? 3.6 Are there any additional costs? 3.7 How about contingency? 3.8 How reliable is the budget? 3.9 Possible reactions to a budget overrun 4. Agile contracting 4.1 Why do we need a contract? 4.2 What kind of a relationship are you looking for? 4.3 What is an iteration? 4.4 How about scope changes? 4.5 When can I get out of the contract? 4.6 Is it finished? 4.7 What about deliverables? 5. Agile contract models 5.1 Fixed price with fixed scope 5.2 Time and materials with variable scope

5.3 Capped time and materials with variable scope 5.4 Capped time and materials with fixed scope 5.5 Incremental delivery 5.6 Bonus and penalty 5.7 Fixed profit 5.8 Target cost 6. Conclusion 7. About the author

1. What is this book about? This book will help you understand why budgets and contracts are crucial success factors of your agile project. It includes clear budget examples and contract models to make your life easier when facing the task of creating a budget or contract for your own agile project. Whether you are on the client or supplier side, when you are involved in creating a budgetor contract for an agile project and want to prevent undesirable outcomes by design, then this book is for you. This book is particularly useful if you are a: product owner project manager program manager portfolio manager contract lawyer As a warning, this guide is a short crash-course. I don’t explore millions of different contract models and options. I also don’t focus heavily on the nuts-and-bolts of budgeting you can find that stuff out from other sources. This book is not about creating the perfect budget in Excel or drafting the ideal contract. It’s about creating budgets and contracts that support agile project management instead of hindering it; it is about contract models that support collaboration and mutually beneficial relationships, about understanding where risk is present in agile project management. I focus on the few things that really matter. Don’t get distracted by all the people offering agile certifications, agile coaching, agile books, or agile games when it comes to budgets and contracts. They may be helpful to improve your Scrum process, your delivery speed, your team building, your product quality, but most won’t overcome your failure to fix the common errors that many organizations make in their budget process and contract writing.

On big projects, none of your agile process details matter if you haven’t established the economic basics first.

2. Why agile budgets and contracts? “Plans are worthless. Planning is essential.” ~ Dwight D. Eisenhower Most agile project management books focus on quick delivery, team dynamics, and quality. There’s no need to repeat what they are writing. There are many great books out there. I am just of the opinion that these address only a part of the problem with project management. Many projects are setup to fail from the beginning because of budgeting and contracting, no matter how good you are at delivering. This is because many projects pretend at the beginning of the project to be able to look into the future. What is even worse, people and companies are committing themselves to such predictions. Fixed scope, fixed price, and fixed time sound familiar? We should accept that this is just crap and adjust our budgeting and contracting processes accordingly, on both the client and supplier side. This is especially relevant for agile projects, since commonly used budget processes and contracts actually hinder agile delivery. I know the agile manifesto says client collaboration over contracts, but it does not say you do not need contracts at all. And anybody who has worked on larger IT projects knows that they are a necessary part of the game. Yes, even when you are not using any external suppliers, you still have contracts. Your own employee contract, your project charter that you just presented at your steering committee, and your guaranteed bonus/promotion when you deliver this project for your manager. Some numbers can help us understand the size of the problem with project management, and why many end in lawsuits: One out of six IT projects has an average cost overrun of 200 percent and a schedule overrun of 70 percent. Around 45 percent of

companies admit that they are unclear about the business objectives of their IT projects. (Harvard Business Review) A study of 5,400 large-scale IT projects (projects with initial budgets greater than $15M) finds that 17 percent of large IT projects go so badly that they can threaten the very existence of the company. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. (McKinsey Study) As per an IBM study, only about 40 percent projects meet budget, schedule, and quality goals. (Harvard Business Review). We are not even talking about promised scope! About 75 percent of IT executives expect their software projects to fail. (Geneca) The US economy loses $50-$150 billion because of failed IT projects every year. (Gallup Business Review) Around 60 percent of companies do not measure ROI on their projects. (KPMG New Zealand: Project Management Survey 2010)

3. Agile budgeting There is a ton of literature and training material about agile estimating and planning. My personal recommendation would be the book and online course by Mike Cohn on this topic. But even after this training, it is still unclear for many how to make the leap from estimations and planning to a sound budget. This chapter will create the bridge between estimations and planning and a sound budget. Although my focus is on budgeting for larger companies, because that is where I have my experiences, I am sure that it can be useful for smaller companies as well.

3.1 Why do we need a budget? “Don't tell me what you value, show me your budget, and I'll tell you what you value.” —Joe Biden Before starting to work on creating a budget, we have to know why we need a budget. This sounds logical, but I have seen many cases where this simple question could not be answered. Why are we actually doing this project? That is why I use a set of eleven questions that together will help you answer the big one: 1. Exactly what problem will this project solve? (value proposition) 2. For whom do we solve that problem? (target market, target users, legal and compliance reasons) 3. How big is the opportunity? (market size, potential savings or penalties when not done) 4. What alternatives are out there? (competitive landscape, alternative solutions/products/suppliers, costs of doing nothing) 5. Why are we best suited to pursue this? (our differentiator as a company or project team) 6. Why now? (market window and urgency)

7. How will we get this project to go live? (implementation strategy) 8. How will we measure success/make money from this product? (metrics/revenue strategy) 9. What factors are critical to success? (solution requirements, skill requirements, budget) 10. What are the main cost drivers? (people, licenses, hardware) 11. Given the above, what’s the recommendation? (go or no-go, continue or stop) The answers to the questions above will guide you in creating a budget that makes sense. It also gives you guidance on scope and timelines. Instead of setting all these things arbitrarily, use your answers above to define these parameters. It is like the old service law. Service can be good, fast and cheap. Pick any two. When your deadline and scope are fixed, you need a lot of money. When time and budget are fixed, then you can only play with your scope.

3.2 Why are budgets a problem? “A budget tells us what we can't afford, but it doesn't keep us from buying it.” ―William Feather Did I not just say that we need budgets? We do, but not all budgets are created equal. The typical large company is organized into cost centers; each cost center must contribute project spending or people (the primary cost element) to the new effort. This creates a number of problems, including: 1. The project budget process is slow and complicated; it takes many individual budgets (one per cost center) to create the project budget. 2. It drives teams to make detailed decisions far too early in the project. Teams are forced to come up with plans that are just guesses; if they can’t identify all the tasks, how can they estimate how many people are needed, and for how long?

3. The assignment of project team members is a temporary thing; the organization assumes people will come back into the cost center for future assignments. If they don’t, other planned projects will suffer. 4. The model drives cost center managers to make sure everyone is fully allocated. However, running projects at hundred percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will be even worse because of time spent on re-planning. 5. The model prevents individuals and teams from working together for longer than the duration of just the one project. This has a negative effect on knowledge acquisition, team performance, and employee engagement. Once the project is initiated, the challenges continue. The actual needs of the business change quickly, and the reality has not much to do anymore with the assumptions that the project made. However, the projects cannot adapt to the changing priorities, because their budgets and people are fixed for the project term. The result is that the organization is unable to adapt to the changing business needs without the overhead of re-budgeting and reallocating personnel. Overhead kicks in; economics suffer. The cost of delay (the cost of not doing the thing you should be doing) increases. But we are not done. Software development cannot happen without takings risks. By its very nature, development is extremely difficult to estimate because it contains a large degree of technical uncertainty. And everyone knows that most things take longer than planned. Moreover, even when things go really well, stakeholders may want more of a specific feature. That takes longer, too. Again, project-based funding hinders forward progress, culture, and transparency. When a schedule overruns for any reason, it is necessary to analyze the variances, re-budget, and re-plan. Resources are scrambled, and reassignments of personnel occur. Other projects are negatively impacted. The “blame game” sets in, pitting project manager against project manager and financial analysts against the teams. Any project overrun has a

budgetary impact. The casualties are transparency, productivity, and morale. So ideally you would fund initiatives or larger programs, not single projects. But the reality in most companies is that funding is on a project level, so let’s have a look at how this can be done for agile projects, and start with the first question you will have to ask yourself.

3.3 Who is creating and managing the budget? Projects are funded in company-specific ways. Usually, a project sponsor gets funding from a steering committee or the CFO. In other cases, a project may be funded out of a specific department's budget. In all cases, there is ultimately a budgetary authority that authorizes predefined or ongoing spend for a project. Any well-run company has a budget process. This process includes the delegation of formal authority to someone in the organization to manage that budget. On projects that use the Scrum framework, that person should be the product owner. In Scrum, the product owner is responsible for prioritizing the deliverables. By extension, this makes the product owner responsible for the allocation of resources for the project and for creating the initial budget. Sounds easy, but this alone already poses a challenge for many companies because the person who gets the role of product owner is typically somebody who is not allowed to handle a budget. Besides this challenge there are all the processes around changes in scope tied to a budget that can only be approved by big groups of people like a steering committee, making any change very slow and troublesome. Maybe even dangerous… “The more people you have to ask for permission, the more dangerous a project gets.” ―Alain de Botton

3.4 Cost per iteration, per team? The two fundamental features of Scrum projects are that they will have a stable team setup and iterations with a fixed duration—for example, twoweek iterations. When you have these two pieces of information, you can

compute the costs per iteration. Sounds simple, but the approach has a few challenges. Let’s start with the team composition. We will assume what is typical for projects in larger companies, which is a mix of internal employees and external contractors and consultants. For each team member, we will need a few pieces of information. Role: Product Owner, ScrumMaster, team member (business analyst, software engineer, tester). Daily rate: Most companies will have a fixed daily rate for internal employees. Based on their level, they will sometimes be different, but typically there is one rate for all employees that includes all costs. External employees will have a daily rate specified in their contract and, when relevant, you should add VAT to this rate to get the real cash-out costs. When you have not yet fixed the rates of the external employees, you will have to estimate them. I prefer to take a range and create a low-cost and a high-cost projection of one iteration. Allocated time on project: In an ideal world, the team members are working full time on this project, but this is often not the case. We will have to determine the percentage of their time that they will be working on this project. Burn rate per iteration: This is the cost that this team member will incur per iteration, under the assumption that he or she will work the agreed allocated time on the project. I always assume twenty working days per month for budgeting. In this example, it's ten days per two-week iteration. I know that people who are allocated 100 percent on the project will not work 260 days a year. Typically this will be around 220 days a year (Switzerland and other countries will have fewer or more days off). Internal/External: For computing the cash-out in your budget, you will need to identify which costs are internal and which are external. An example of internal and external costs for a team:

When you are budgeting a larger project with multiple Scrum teams, you just do this exercise for each team. I budget them separately, which means I will have a line in my budget for each team and do not have a total cost per iteration. This is because not every team will have the same number of iterations. When your project includes project management office (PMO) resources, such as a chief product owner or a program manager, you can do two things: create a separate team for them and do exactly the same exercise as above, or add each one of those resources for a certain percentage to an existing Scrum team. I have seen both, but I prefer the first one and call the team "Program Management." This way, it is very clear that they are managing and not building, and you prevent long discussions regarding team percentages. One other team that I have added to some budgets is the Initiation team. Before everything is in place for a larger project (including a final budget approval), a small team starts the initiation and elicitation of the project. And yes, I let this team work in iterations as well. Why? 1. Management is not willing to commit to starting the project without having a view of the total scope and cost. 2. A business case is required to make a decision whether to go ahead with the project at all. 3. Multiple stakeholders must agree on the scope of the deliverables for the project before it is sanctioned. An example of internal and external costs for multiple teams:

After I have the cost per iteration, per team (including the overhead team, as shown in the example), I can start the next step.

3.5 How many iterations per team? There are thousands of articles and videos on agile estimating and planning, so I will not address how you can do this here. What we will need from each team for our budget is the number of iterations that are planned. This can be done by estimating the product backlog and dividing it by the team's (estimated) velocity. You will not even have to do this for some projects because the time is fixed, and you know the maximum number of iterations up front. The overhead team always has the same number of iterations as the team with the largest number of iterations. When we have this information, we can compute the total project budget for each team. When the project runs over multiple calendar years, you will have to split the numbers by year. This means that you count the iterations per calendar year for each team. An example of total project budget for each team:

3.6 Are there any additional costs? This answer will be "yes" for almost every project. Additional costs are incurred through local hardware and software for the software engineers and testers as well as the infrastructure for the final project. Development

environment, test environment, user acceptance testing environment, and production environment will cost money to buy, set up, and maintain. I do not allocate these costs to a team when it is not forced by accounting. I will add a line for hardware, a line for software, and a line for setup costs (typically an external IT provider or internal IT costs). Other possible costs are travel (for example, one team is at a different location), workshops, and training. Again, these are project costs and not team costs.

3.7 How about contingency? Most companies I have worked for have an obligated percentage of contingency on top of the total budget, or parts of the budget, that typically range from 10 percent to 15 percent. Be careful here, because although you have more money, it is hard to add members to an existing Scrum team. Therefore, this is only usable for running an additional number of iterations. So you’d better make sure you do not have a fixed scope / fixed time contract when working with agile teams.

3.8 How reliable is the budget? Unfortunately, serious, realistic planning is impossible at the start of a software project. This is true for conventional and Scrum projects and does not reflect the team or service provider’s capabilities. It is due to the nature of complex IT projects. But unlike in waterfall projects with detailed requirements specifications, Scrum embraces this impossibility, so the initial estimates in Scrum are not fixed. They become more realistic over time. As soon as the project starts, the requirements and general conditions become clearer with every passing iteration. And by using proven estimation methods and gained experience, the team becomes better at determining how much a desired feature will affect the budget. After just a few iterations (which is very early in the course of a bigger project) the project sponsor has reliable and valid information about the required budget.

Besides creating a more reliable budget by design as part of the Scrum process, Scrum projects guarantee transparent budget control on the way. Cost explosions, which might need to be accepted in a Waterfall project if you want to actually see your software in the end, can be avoided with Scrum. The project sponsor will still receive a high-quality software product, albeit with fewer features than initially planned.

3.9 Possible reactions to a budget overrun What happens if, after a few iterations, the estimates are much higher than the initial estimates? Does the project sponsor lose all control over the budget in Scrum projects? The opposite is actually true. The project sponsor always has options due to the new, incoming information about the total budget. This is one of the main advantages of Scrum. Early on in the project, the project sponsor has functional software containing the most prioritized functions and offering the greatest benefit. In this case, the project sponsor has four options: 1. If meeting all requirements is expected to cost more than budgeted, the project sponsor can abort the project at an early stage. A basic version of the project is generally released after just a few iterations. 2. The project sponsor can let the project run until the planned budget is consumed and then suspend or terminate the project. In any case, they will have functional software that contains the most important functions. 3. The project sponsor has the option of changing the project scope by postponing or omitting less important functions. 4. The project sponsor can increase the budget. Scrum allows the project sponsor full budget control and thus full flexibility while reducing the risk of cost explosions because of big-bang implementations.

4. Agile contracting “Contract law is essentially a defensive scorched-earth battleground where the constant question is, “if my business partner was possessed by a brain-eating monster from beyond space-time tomorrow, what is the worst thing they could do to me?” —Charles Stross

4.1 Why do we need a contract? A contract is a voluntary arrangement between two or more parties that is enforceable by law as a binding legal agreement. So as soon as there is more than one party involved in a project, you will need a contract of some kind. The most rudimentary forms are just a piece of paper with a signature or an email. In the kind of projects I am typically involved in, there are usually multiple companies working on the same project: external consultants, external developers, outsourced infrastructure, third party software, component suppliers, and so on. This will lead most certainly to a larger number of different contracts within one project. As a client or supplier of services at the beginning of a project, you know better than to work with just a verbal agreement. There is just too much at stake for both parties. Although the Agile Manifesto values client collaboration above contracts, contracts are necessary when working with external suppliers. A contract is just a set of written rules. The right rules increase the chance of success for both parties. The wrong rules make working together successfully more difficult. When working with large companies, there are often standard conditions that must be accepted to do business with them. These conditions are seldom fair, so a reasonable project outcome depends heavily on a good relationship between client and supplier and avoiding recourse to the contract of law. Because when you have to, typically both parties do not get what they want.

This is the case with waterfall projects, but even more so for agile projects. This is because most existing contract types within large companies are not suitable for agile projects. They do not incentive the supplier to do its best/fastest work (time & material) or try to put all risk on the supplier (fixed cost). The structural and legal aspects of agile project contracts are the same as for contracts of more traditional development styles. The key difference is the approach to, and understanding of operational process and delivery and how this is included in the contract. An understanding of agile and lean principles is necessary for procurement. Applying iterative development leads to less risk and exposure, and that needs to be expressed in the contract. An agile approach enables rapid incrementally deployable deliverables and collaborative decision-making between the parties, and so relieves pressure on liability, warranty, and similar issues. Do not assume that contract negotiations are less complex for procurement departments who understand agile principles. It is important to recognize that contracting is a complicated process, especially in a domain of high complexity and uncertainty such as software development. Lawyers must continue to pay close attention to the legal framework that is necessary to deal with a breakdown of trust and collaboration between parties.

4.2 What kind of a relationship are you looking for? Contracts reflect people’s goals and, especially, fears. Successful projects are not delivered by contracts, but from relationships based on collaboration, transparency, and trust. Successful contracts contain rules that support the building of collaboration, transparency, and trust. As trust develops between the client and supplier, the contract model should relax and support a better client collaboration over contract negotiations. Relationships can be categorized in four different attitudes:

1. competitive (my win is your loss) 2. cooperative (win - win) 3. indifferent (I do not care - you lose) 4. dependent (heads I win - tails you lose) These relationships are typically driven by the party who is carrying the risk of failure. We will discuss this in the next chapter at the hand of our discussed contract models.

4.3 What is an iteration? For procurement departments that are new to agile delivery models, it is important to understand the concept of iteration and what it means in the context of delivering that which is part of the contract. An iteration can be summarized as following: At the end of each two-week (or up to four-week) time boxed iteration, deliver a deployable system with useful features. It may have insufficient functionality to be a candidate to deploy, but with each iteration, it is getting closer to be a deployment candidate. Incremental delivery is not a new concept in contracts; many identify intermediate milestones, either fixed by date or by goals with associated acceptance criteria or a statement of work. The noteworthy differences for procurement departments regarding iterations and milestones in agile delivery are doneness and timeboxing. Each iteration delivery is done, programmed, tested, and so on, and is in theory deployable. Each iteration is of fixed time but with variable scope.

4.4 How about scope changes? “It does not take much strength to do things, but it requires a great deal of strength to decide what to do.” ―Elbert Hubbard The issue of change is addressed within the overall philosophy of an agile delivery approach because of a prioritized backlog and adaptive iterative

planning. So no special change-management process, board, or request mechanism is needed. It is critical for procurement departments to remove old change-management language from contracts because such language typically blocks working agile. Change in project scope requires the most attention in an agile contract in order to make change easy and frequent in the collaboration between client and supplier. Avoid mandating change-management boards, change requests, or special change processes. But, as with project scope, there are variations in change-management flexibility, ranging from high flexibility without penalty when using flexible scope contracts, to medium flexibility with shared gain/pain when using target-cost models.

4.5 When can I get out of the contract? The concept of termination is an important one in an agile project. It should be possible to change the direction of the project (scope, supplier, technology) to the point of actually stopping further effort at the end of any iteration. In contrast to conventional project thinking, procurement departments need to understand that early termination should be viewed as a positive, desirable event in an agile project, because early termination does not automatically mean failure. It can mean that success was achieved quickly. Learning fast that the path taken is the wrong one is also a success. Sunk costs are minimized. Arguably the ideal termination model in an agile contract is to allow the client to stop, without penalty, at the end of any iteration. Naturally, if the supplier has dedicated hundred people for an anticipated two years, and termination is unexpectedly much earlier, they likely have an expensive problem on their hands. Hence possible contract rules include a sliding scale of penalty to the client that reduces over time (and iterations). Termination can be one of the most difficult areas to negotiate in any contract. The key mitigating differences in an agile approach are that (1) the client has a working system at the end of each iteration, and (2) both parties

will have clear and up-to-date views on the state of the deliverable. These are crucial points for procurement departments to grasp.

4.6 Is it finished? “Is it finished?”- “What to do if not finished?” - “We have now decided to change our minds and reject the iteration delivery from three iterations ago. Do you mind?” These are vital questions in outsourced project work, and unclarity around such issues is a possible source of conflict and litigation. Clarity regarding finished, acceptance, and correction both in the minds of the parties and the contract language is an important issue to address for procurement departments. They can help considerably in negotiating a contractual framework for acceptance that encourages collaboration. Acceptance still exists, but is much simplified because of iterative delivery and acceptance, and because acceptance is incremental and adaptively agreed upon for each iteration. Further, agile practices usually include highly automated acceptance testing so that little or no manual (human) effort is required for validation. Acceptance builds upon itself such that the final acceptance is the culmination of a number of acceptances that have occurred throughout the life cycle of the project, ideally most being repeatedly verified with automated acceptance tests. In terms of contract work, this means that acceptance definition and negotiation does not have to be a massive comprehensive exercise; only the framework for acceptance must be contractually clear. Broadly, for each iteration, acceptance is based on conformance to a prior agreed-on acceptance-test set, and in the case of Scrum, in conformance with the “definition of done.” Another element of acceptance in agile development worth considering in the contract framework is to include candidate users of the new system in the definition of acceptance and acceptance testing. Procurement departments concerned with a successful project should ask, “Are the right

people, i.e. the hands-on users, involved in acceptance, and at each iteration are they collaborating with the supplier?”

4.7 What about deliverables? Traditional project contracts often include a detailed, prescriptive list of what should be delivered. Typically a lot of different documents. These details are sometimes embodied in a statement-of-work or “quality plan” appendix. You should avoid such detailed deliverables list in the contract. This only leads to an increase in waste activities rather than a focus on working software, and there is a presumption, possibly untrue, of knowing what artifacts are valuable. Besides that, it makes the assumption that a fully defined system can be predictably ordered and delivered as though it was a burger in a fast food restaurant rather than creative discovery work. Discovery of valuable deliverables can be more simply achieved through frequent incremental delivery and deployment, rather than through a contract deliverables list. What you should never forget, however, is the source code of custom software. I have been on multiple projects where this has become an issue. Especially when all development is done at the location of the supplier, and not the client. Your procurement department should also think about the source code of products you buy in the case the supplier goes bust. Escrow is your savior. On occasion, technical documentation to support maintenance is valuable, usually as a learning aid for people new to the system, and its delivery is often specified in a traditional project contract. Yet, maintenance of a recently deployed system is frequently outsourced to the same people that created the system and so they have less need for such documentation. Therefore, it could be wasteful to require it as an early deliverable. If, at some future time, there is a demonstrated need for documentation for the client (for instance, if the client takes over the maintenance work), then it can be created by the supplier, perhaps in a joint agile documentation workshop with the client after the system is finished.

5. Agile contract models “A valid contract requires voluntary offer, acceptance, and consideration.” —Robert Higgs This chapter will discuss a number of different contract models by using hands-on examples. The eight contract models we discuss are: 1. Fixed price with fixed scope 2. Time and materials with variable scope 3. Capped time and materials with variable scope 4. Capped time and materials with fixed scope 5. Incremental delivery 6. Bonus and penalty 7. Fixed profit 8. Target cost For each model, we discuss scope changes, risk, termination and client/supplier relationship. I can really advise you to have a look at the different forms and think about this before you structure or sign your next contract. You can combine many elements of them into the model that is most suitable for your specific situation. Before we discuss the different contract models, I would like to talk about the concept of an iteration contract. This concept is helpful in understanding the relationship between product owner and implementation team. This is not really a commercial contract, but simply the agreement between the product owner and the team for one iteration. The implementation team agrees to do its best to deliver an agreed set of features (scope) to a defined quality standard by the end of the iteration. Ideally, they deliver what was promised, or even a bit more. The product owner agrees not to change his instructions before the end of the iteration.

So a Scrum project is simply a series of mini projects with fixed parameters: Time: iteration length Scope: iteration backlog Quality: definition of done Cost: team size * iteration length Without exception, you can apply this concept within any of the following contract models. All contract models will be explained at the hand of one simple example. A project with around 110 person days of work, the daily rate is $ 1500, and the profit margin of the supplier on this rate is 20 percent, i.e. they earn $ 300 on every person day sold for $ 1500.

5.1 Fixed price with fixed scope Agree on the deliverables, and deliver it. Send a bill. Clients like fixed price projects because it gives them a sense of security (or at least they think so).

Scope changes would lead to a change of contract and new negotiations. Very inflexible. Termination is typically at delivery of full scope, or after the client has paid the penalty to get out early. Obvious risk is on the side of the supplier. If the estimates are wrong, the project will lose money. Less obvious risks are the change request game, through which the supplier negotiates additional revenue through scope changes. If the supplier had badly underestimated the effort or quoted an unrealistically low price, the losses could threaten the existence of the supplier, which also represents a problem to the client. The relationship between client and supplier is competitive to indifferent. The client generally wants to have more, and the supplier wants to do less. The supplier wants the client to be happy, so usually the supplier yields. The word “et cetera” is very dangerous in a specification to a fixed price. All project managers should be familiar with this kind of type, because every one of them basically “signs” one when they present their project charter document to their Steering Committee. Boom, scope, time and budget fixed…When you are forced to do this, make it a Waterfall project, because it has nothing to do with agile project management.

5.2 Time and materials with variable scope Work for a month, then send the client an invoice. Suppliers like it because the client carries the risk of changing his mind.

Scope changes are not an issue. The client can decide what the supplier should work on. Every person day is paid. Termination is as soon as the clients say so, it ends. Typically, with a month or so upfront. The risk is carried one hundred percent by the client. The supplier has little incentive to keep costs down. Effort to ensure that only legitimate effort and expenses are invoiced can be substantial. The relationship is indifferent. The supplier is happy when more work comes because more work means more money. Recommended for projects where the client can better manage the risk than the supplier. This is often combined with a cost ceiling, although this can degenerate into a “heads I win, tails you lose contract” if too much pressure is applied on the price.

5.3 Capped time and materials with variable scope

Capped time and material contracts work in the sense of traditional time and material contracts. However, there is an upper limit to how much customers will have to pay. In this way, suppliers benefit with early timeframe changes while clients only have to pay up until the capped cost limit is reached.

Scope changes are not an issue. The client can decide what the supplier should work on. Every person day is paid. Termination is as soon as the clients say it ends. Typically with a month or so upfront. The biggest risk is that the budget will expire without achieving the necessary business value for the client. The client won’t get everything he asks for. The relationship will be cooperative. The combination of limited budget and variable scope focuses both client and vendor on achieving the desired business value within the available budget. Smart way of handling such contracts is confirming an iteration contract in writing (e-mail) at the beginning of every iteration.

5.4 Capped time and materials with fixed scope Capped time and material contracts work the same as traditional fixed price, fixed scope contracts, except if the vendor gets finished early, the project costs less, because only actual effort is invoiced.

By a change management process as with fixed scope / fixed price contracts. Termination is upon completion, after paying the penalty, or after agreement of both parties. This appears to represent the ‘best of both worlds’ from the client’s point of view. If it requires less effort than expected, it costs less. But once the cost ceiling has been achieved, it behaves like a fixed price project. The relationship is a dependent one. From the supplier’s point of view, the goal is to hit the cost ceiling exactly. There is no incentive for the supplier to deliver below the maximum budgeted cost. The client has probably treated the project internally as a fixed price project, and so has no incentive to renounce scope to save money.

5.5 Incremental delivery Incremental delivery contracts allow customers to review contracts at designated points in the contract life cycle. These points are negotiated into contracts and allow customers to make changes, continue, or terminate the project. For example, fund quarterly releases and approve additional funds after each successful release.

New business goal for each release, compatible with a product backlog prioritized by the product owner. Both sides can decide to end the collaboration after each phase. Client’s risk is limited to one-quarter’s worth of development costs.

The relationship will be cooperative. Both the client and the supplier have an incentive that each release be successful, so that additional funding will be approved. This mixes well with capped time and materials with variable scope. You can specify the release goal, daily rate and cost ceiling in the contract. The client provided the product owner. Everything else is determined in the iteration contracts.

5.6 Bonus and penalty The supplier receives a bonus if the project completes early and pays the penalty if it arrives late. The amount of bonus or penalty is a function of the delay. Often applied for construction projects, e.g., roads, tunnels, and runways, for which it works well. Scope changes are not an issue, and genuine economic costs drive the client to achieve the deadline as well. With IT projects, this is a sure setup for lawsuits.

Changes: difficult to accept because changes potentially impact the delivery date, which is surely not allowed.

Does the client have an incentive for early completion? The ROI arguments must be compelling and transparent. Otherwise, the client gets a cheaper solution the longer it takes. Could be cooperative, but might degenerate into indifferent if the client does not truly need the software by the date agreed.

5.7 Fixed profit Any project budget consists of effective costs and profit. The parties agree on the profit margin in advance, e.g., 20 percent. The client can back out after “any iteration” by paying a cancellation fee of the profit part of the remaining effort.

Can be variable - it is possible to finish early. This only works with agile development, because only agile methods deliver software incrementally. Risk is shared. If project finishes early, the client pays less, but the supplier still has his profit. If the project exceeds budget, the client pays more, but the supplier does not earn additional profit. After the target delivery date, the supplier may not invoice any more profit, just cover his costs.

Cooperative - both have a clear incentive to finish early. The client saves money, and the supplier has a higher profit margin.

5.8 Target cost In target cost contracts, parties involved with the contracts agree on a final price during negotiation. These contracts allow cost savings for both parties if contracts run below budget, but also allows both parties to be faced with additional costs if contracts run above budget. This is a combination of several approaches. Work is basically on a time and materials basis with a cost target. However, the intention is that the project will not use up the entire project budget. After a certain amount of functionality has been delivered, the client should realize that enough business value has been realized that further development is not necessary and can, therefore, cancel the project. A cancellation fee equal to the remaining profit is due.

Can be changed. Planned but unimplemented features can be replaced with other stories of the same size. Additional features cost extra.

Risk is shared. Both parties have an interest in completing the project early. Client has lower costs; supplier has a higher margin. Cooperative - both have a clear incentive to finish early. The client saves money, and the supplier has a higher profit margin. If the budget is exceeded, the rules of the fixed profit or cost ceiling contracts can be applied. The fixed profit approach is more consistent with the goal of fostering a cooperative relationship.

6. Conclusion In order to run your project in an agile way, you have to make sure your budget and your contracts support the way you want to run it. There is no one size fits all, but in general, you can say that reserving a budget, but releasing it to the team on a sprint to sprint or quarterly basis works very well for bigger projects. For very large projects, the first thing I would advise to do is split it up into smaller projects. Large projects have the tendency to fail, no matter how you run them, and it is impossible to focus efforts when the project has fifty plus parallel deliverables planned. In almost all cases, it is unnecessary to run one very large project. Keep your efforts manageable and focused. For new technology projects and products, make sure you run a proof of concept/prototype project first. Sunk costs in the case of failure are far much lower, and cost of delay are much lower in the case of success. Regarding contracts, I am a big fan of the target cost and incremental delivery models. Of course other models can work well depending on the situation. But no matter what you do, I would advise using iteration contracts when you work in an agile way. They can be informal short emails, but it sets expectations for all parties involved, and this is never a bad thing.

7. About the author

Henrico Dolfing has been a project rescue consultant for almost a decade. His company Data Solutions advises companies in the financial sector on large IT projects. His expertise in software development and experience with agile processes and techniques allows him to rescue projects that are in critical phases on the verge of failure and lead them back to success. Born in the Netherlands, one of the flattest countries in the world, Henrico spends all his spare time in the Swiss mountains enjoying alpine marathons, climbing, downhill mountain biking, river rafting or leisurely hikes with his wife. Connect with Henrico on LinkedIn or Email LinkedIn: http://ch.linkedin.com/in/henricodolfing Email: [email protected]