Agile projects: a customer perspective
As the customer or project sponsor, the details of agile software development are of little interest to you. Nor do you need to be concerned with the technology of and tools for managing the project. On the other hand, how agile methods influence approaches to budgets and deadlines will be your concern. Because the question is can a web integration project based on AGILE principles be equally well managed and controlled as a traditional project?
Today, agile approaches and methodologies are well-known and abundantly used tool in the software world. Most of them (such as SCRUM, the most familiar) were and basically still are primarily a development methodology. The agile approach is not just about how to develop software; it also has necessary impacts on how the project is managed, how to handle and control the budget, on how to conduct business agreement and cover it by a contract. When using agility for company internal development and internal projects (by the internal IT department) the impacts are not as fundamental as in a situation where you, as the client, would like to conclude a contract with a company wanting to apply agile approaches to a project, including project management.
Let’s take a look at the difference between classical project management in the form of a “project triangle”.
In the traditional approach, “fix time – fix price“ contracts (FTFP) are used most often, but in fact the most common contractual arrangement is fixed scope, i.e. the functional scope of the project and resultant product. The timing and budget here do not result from actual workload estimates but often from business negotiations between the parties, and a declaration of intent by the client, as opposed to efforts to transfer all risks to the supplier.
In the attempt to outline the functional scope as perfectly as possible, very detailed analyses are carried out, before the agreement on an implementation contract. The implementation team then delivers on the contract outputs (in an effort to adhere to the fixed scope), regardless of any changes in external circumstances or the customer's business priorities. And with an approaching and budgeted hourly limit being used up, quality is often affected. The resultant work is often not completed on time, discussions are held on “extra work”, and the product is defective. On paper, the customer has the FTFP as promised, but the result is often exactly the opposite of what is intended – in the project outcome time and financial aspects are changeable because of a rigidly fixed scope!
The basic idea of the agile approach centres around the “reversed project triangle”, which says that for a project a certain amount of time is allocated (and you must stick to it), you know how to invest a certain amount of money (and you want to adhere to it), and you want to maintain a certain level of product quality (which you do not lower). These parameters are truly fixed. The only variable in the project is the scope of the functions that can be realistically delivered under the time and money constraints, i.e. functional scope. To a certain extent in traditional methods, change requests are the nemesis of the client and the project manager. Therefore, in the agile approach change suggestions are, both very welcome and desirable. They can reflect changes in circumstances and priorities, and allow new ideas to be introduced in the project and improvements, including by the implementation team. Given the logic of the reversed triangle, this does not automatically mean a change of the deadline or time, but only that the most important and beneficial is chosen first, and perhaps at the expense of something less fundamental. This logic is not at all strange to people – we are all often confronted with a scenario like this: I have six months, and 2 million, and how do I use it best?
Naturally, even a project conceived this way cannot start without a brief, and without setting the fixed parameters of the triangle. However, the document created is not very detailed – on the contrary, an attempt is made to describe only the basic limits and so called “foundations” of the project, forming the basic framework, from both the substantive, and business and management, perspectives. From the solution perspective, the document will then describe the main goal and the business benefit (i.e. WHAT I want, but never HOW it will be delivered).
Naturally there is also a need to set budget and time constraints, where we come across a sensitive issue in this approach. Without a detailed analysis, technically varied bottom-up estimates cannot be applied. Instead, expert estimates, industry benchmarks, and analogy should be relied on. And they need to be realistic! Time and money constraints must be set, to realistically enable the creation of at least a basic solution that is viable (Must have). Here it is appropriate to use a technique called “MoSCow”, for example, which classifies high-level business requirements as:
- Must have (must be fulfilled; otherwise we cannot “launch” the product, it will be useless, and the project will fail)
- Should Have
- Could Have (sometimes referred to as ”nice to have“)
- Won’t have (it will not be considered in the solution; we will not spend a single second discussing it)
At the beginning project setup should be in line with the expert estimate for implementing the “Must have” and “Should have”. If the implementation runs smoothly, even more will probably be more achieved! If things worsen, a certain level of spare capacity is available. Of course, as mentioned above, the priority of requests during the project can and will be changed!
A project already set this way is, from the operational PM perspective, relatively easy to manage. Changes in the scope and priority requirements are particular to the agile approach. Key “managerial” changes involve only decisions on resetting the time and budget limits.
Control of the project is essentially continuous in agile approaches. All agile methodologies have common approach to handle project at certain time intervals, iterations, generally called "time-boxing". After each such iteration, the achieved result and the functions is revised by the contractor. After each iteration, the priorities for the future are re-evaluated for the next iteration, and the implementation team performance is assessed. In the project early stages it is clear how the development is progressing and whether a result will realistically be achieved. Given that these projects are working mostly in fixed teams, the price for each iteration is determined by the team size and therefore easy to predict.
If it turns out that the time and financial constraints will not allow delivery of at least the minimum viable functional product, it is unpleasant and the expert appraisal has evidently failed. Even so, such information emerges much earlier than in traditional projects! It is up to the customer whether the management will purchase the next iteration and capacity or, as the case may be, the project stops. Likewise, at any time the customer may choose to make a time shift or increase the budget because it wants to carry out more optional or new requirements (and a complicated contract in this does not restrict either party in further cooperation).
Of course I do not claim that such a project approach is suitable in all assignments. Often a detailed analysis is already available or the solution is so technologically complex that there is no room to make changes (introduced for commercial reasons). But often it is more suitable for general commercial briefs in which the software or online application supports certain primary business of the company.
In conclusion I would like to mention two things that are a possible obstacle but also an important condition for successful partnership between customer and supplier in the spirit of such an agile arrangement.
The first is that the willingness of the customer to be increasingly involved in the project. The customer representative must be the lifeblood of the project, be involved in evaluations of individual iterations, be flexible in revising priorities and discuss with the implementation team ideas for improvements. It will not work if the client approach is “here is the brief on an A4 sheet. I don’t want to see you before the project is submitted. You are professionals so I expect a perfect result. And most of all, don’t ask any more questions.”
The second is the establishment of a specific partnership and a relationship of trust. Such a model works better with a supplier that the customer already knows through previous experience. Where it knows that it knows how to provide a particular solution (or has clear references for doing so) and trusts the impartial expert assessments and estimates of the supplier’s consultants. On the other hand, if as the client, you do not believe that the supplier will deliver successfully, you should not go with this company or the classic FTFP, either. Or should you?
Naturally, there are many more detailed methods, tools and templates for project managed under the agile project concept, but the basic ideas, and certain paradigm shifts are outlined above. I work in the IT projects sector, as supplier and have been doing so for almost 15 years. “Playing at” bullet-proof analyses, contracts, and painful negotiations for change requests resulting from unfulfilled expectations makes me really exhausted. And I often see such exhaustion on the client side. And how about you? An agile project conducted in an atmosphere of trust can be not only more successful but more pleasant for both parties!
PS: certain visualisations and concepts in this article are taken from the www.dsdm.org website. I believe DSDM is a very interesting agile framework that, unlike others, deals both with the development AND the project management aspect of agility. I recommend that those in the customer team familiarise themselves with it!