Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Management Information  Management Information   Agile and the PMO   Agile and the PMO

The role of customer is identified in many agile methods and is given many different titles.

Throughout the Toolkit we try to use one term to identify the customer role: the business.

This covers the role of customer, customer user, super user, customer representative, senior user, user, product owner and product manager. There are many customer roles within an organisation and we will attempt to distinctly identify these wherever possible.

In a customer to supplier relationship, invariably there is an account manager responsibility within the supplier organisation. The account manager is the first point of contact with the customer in this relationship and is responsible for all new and existing sales to the customer. The objective of the Toolkit is not to define the roles and responsibilities of an account manager. However, the Toolkit does define the interface between the customer and the account manager, but only in relation to agile project activity.

The new agile project does introduce new challenges to that interface. In a traditional project, where new requirements are identified outside the original requirements as defined in a requirements document, these are classed as new requirements that demand change control. The account manager invariably proposes that this is therefore a new sale to the customer. The customer and account manager agree a price and a proposed delivery date. If this results in new work for the project team, the project manager is informed and the new work is planned into a revised schedule.

In an agile project, the circumstances are different and we have some simple methods to overcome this when you use the Toolkit. In an agile project, we have a requirements list. We also have a Build and Fix List. The requirements list defines what we want. The Build and Fix List defines what we are going to do. If the requirements list as well as the Build and Fix List do not change, then we have a stable requirements target. With a stable requirements target and enough time and resources to deliver those requirements, then there are no account management challenges. The challenges arise when either the requirements list or the Build and Fix List change.


These challenges, however, are straightforward on an agile project.

As the new requirements arise, they are added to the requirements list. Each requirement is allocated a priority. A decision is made by the project team to include or exclude the requirement from the Build and Fix List. If the requirement is excluded from the Build and Fix List, then there are no account management challenges. If the requirement is included in the Build and Fix List, then there are still no account management challenges. Let us explain.

The project team will decide the amount of work left to do and, based on the amount of time left, they will decide which priority work is to be completed. If the new work is added to the Build and Fix List then a piece of work of equal size and effort must be removed from the Build and Fix List. Almost all agile methods used this, or a similar, form of work allocation. This ensures that only priority work is delivered.

It ensures that the project team deliver only those requirements that the business want. It also ensures that the project team do not outstretch their capability by attempting to perform more work than the remaining time allows. They adjust the work they are going to do using the same number of people and the same agreed amount of time.

So, you can see, there are no change control activities in such a discovery-led and change-friendly environment. Therefore, there appear to be no new sales opportunities for the account manager. This flies in the face of the account manager work description. Their objectives are to maximize revenue opportunities for the supplier on this project. Patently, if no new people are demanded then the supplier looses the revenue stream that comes from adding more and more people to an existing in-flight project.

Their objectives are also to seek out new revenue opportunities within the customer organisation. This is the first opportunity an account manager can investigate. This opportunity involves the circumstances where an element of requirements, identified by the business, is either removed from the Build and Fix List or is not added to it. This is an opportunity for the Account Manager to investigate the will of the business to satisfy these requirements and to deliver some solution to address them.

This is where new sales opportunities arise. Here the account manager has the opportunity to set up a new contract, a new schedule, a new project or a new subproject to satisfy these outstanding requirements and to deliver a solution to bring them about. The challenges involved in a new sales negotiation, in these circumstances, are reduced. By this time in the progress of a project, the customer will already see identifiable output required by his or her business that the supplier has successfully delivered.

The customer will also see that the supplier, and therefore the account manager, delivers what they said they will deliver. The customer, especially if they have not worked an agile projects before, will be starting to understand the process better. They will see that the supplier is unable to stall or slow down a project in the hope of adding more people near the end of a project to add more value and revenue to their supplier contract. They will also identify that they, as the customer, are unable to add more and more requirements in the hope that this extra work can be done for free.

The new way of account management within an agile project involves an arrangement where you share and collaborate rather than prey and hunt for hidden opportunity. This is not too much of a change for an account manager who has a responsibility also to maximise the quality of the delivery for the supplier. This is done in order that the customer will recognize the benefits of using the supplier and thus request further solutions.

Setting and establishing sales targets for agile projects is a little more tricky. It is difficult to know from the outset of a project what proportion of new requirements will be requested during the life of the project. It is also difficult to estimate how many of these new requirements will not reach the build and fix list. So it is difficult to estimate how many new smaller projects will be generated from this one piece of work.

As a customer becomes more and more conversant and capable with agile techniques, their scope definition of the projects improves and the likelihood of new requirements appearing during the project therefore diminishes. It gradually transpires that the customer identifies one or more new projects themselves. It also means that the customer begins to develop a more embedded and localised way of performing their own agile projects. This means it is vital that a supplier gets their agile relationship with their customer right, from the outset.

Finally, one other area of an agile project is of interest to the account manager. This is a practice we call Scope Cheap and we deal with it in detail elsewhere in the Toolkit. For now, let us say, it involves the circumstance where a project team identify elements of requirements that can be delivered as part of the current work with almost no additional effort involved. For example, let us imagine that there is a requirement as part of your project for a management report. Let us also imagine that this report was requested to have a final total.

During the life of the project, the business identify that they need a sub total split by Department. As part of the project during the daily forum, the project team will identify that this is a simple extra edition. Furthermore, they will confirm that this piece of extra functionality can be very simply added to the build and fix list and delivered as part of the project. For the account manager, this is a very important piece of information.

This is extra work. It is very small extra work, agreed. But the customer is getting extra functionality and you, the supplier account manager, have delivered this without any change control. Using the Toolkit, you have techniques for your project team to deliver such swift solutions without fuss or chaos. However, as we said before, this is a very important piece of information. The account manager will collect this data at the daily forum. When the account manager comes to negotiate the next new pieces of work and the next new sales, this data is demonstrating your collaborative approach and evidencing the suppliers ability to deliver quickly and with integrity.

So you can see it is important that you attend the Daily Forum or get an accurate appraisal of its conclusions. If you have the role of account manager with customer liaison responsibilities and cannot regularly attend the Daily Forum, your challenges will be accurate stakeholder management and status reporting. Therefore you need a distinct way to gain an appraisal of project issues and status. High velocity projects can very quickly drift away from the assumptions and expectations of those personnel who are not directly on the project.

So to demonstrate your command of the project and to inform your customer wisely and accurately you, as well as members of the project, will expend some effort to keep you up to date with the wider view your customer needs. If you are a very lucky Account Manager and have free time throughout the day then you may have the opportunity to call up the project manager and get this appraisal. However, nine times out of ten, your project manager will not have this free time also. This is where a Project Management Office (P.M.O.) function can assist. Let us look at what this can do for the project and the Account Manager.

Buffer



 Management Information     Management Information   Agile and the PMO    Agile and the PMO



Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z


#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Agile and Account Management






   


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
   
Topic: 53  Page: 54/444  Progress: 12.2%
 About    |    Author 
Follow @BigAgileToolkit


This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL (http://www.bigagiletoolkit.com/) and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.