Tag Archives: Scope Creep

Things I Learned Managing Fixed Price Agile Projects

Posted on by
Reply

When it comes to managing Agile projects, Jesse Fewell is the expert.  He’s one of the founders of the PMI Agile Community of Practice and a senior adviser on the PMI-ACP certification.  And he recently conducted a webinar on managing fixed-price Agile projects.  A fixed-price contract is essentially a vehicle for transferring cost risk from the customer to the service provider.  Consequently, it is incumbent on the service provider to manage that risk, in terms of deliverables, quality, and schedule.

Typically, risk is accepted at a premium, so a well-managed fixed price contract can be more profitable than a time and materials contract with the same SOW.  As the project manager, you are responsible for more than just the deliverables in the SOW.  You are also responsible for triggering invoices for progress payments and managing to the constraints specified in the contract.  Given that I’m currently managing two fixed-price Agile projects, I thought I’d add my observations.

  • When the price is fixed, change management is your only tool for staying out of the red.  Any change in scope has to be documented in a change order, and funded as provided for in the overall contract.  If the menu says dinner comes with soup or salad, you’ll have to pay extra to get both.  IT projects should be managed on the same basis.
  • Have a clear delineation of responsibility with the customer on the process for vetting and approving change requests.  By time the request gets to you, it should consist of “What will it cost us to change …” and it should have already been reviewed by the steering committee as something they are willing to approve funds to get.  Otherwise, you will find yourself typing up someone else’s letters to Santa Claus.
  • On a time and materials contract, activities are billable. On a fixed-price contract, your progress payments will be tied to specific, well-defined deliverables.  Well-defined means there is an existing template for this deliverable, and it’s been delivered before on similar projects.
  • A well-written contract will have a clause that each deliverable will be deemed accepted unless specific objections are raised in some number of days.  Ensure your customer identifies who will inspect each deliverable, and briefs them on acceptance criteria and how much time they have to perform the inspection at the beginning of the project.  Make sure they understand their role.
  • Interaction with the customer is a key Agile tenet, but not all interaction is created equal.  Some meetings are necessary in order to produce the deliverables in the SOW.  Other meetings are necessary to manage the project and coordinate work planned and in progress.  Push back on all other meetings, because those are activities, and you’re not getting paid for them.
  • If you are unlucky enough to get a contract with both a fixed price and a fixed delivery date, you must put a due date on every client input, and document every delay.  This is especially true if there are liquidated damages in the contract.  Remind the customer that delays on critical path tasks delay the delivery date, day for day.  Yours are not the only feet facing the fire.
  • If change management is not in your SOW, it is not your responsibility.  But it is someone’s responsibility, and you need to keep one eye on them.  Ensure the customer understands the importance of communication, training, preparations for support of the system in production, and the dozens of other details, great and small.
  • The scope of testing has to be clearly defined, and acceptance criteria specified.  The pursuit of perfection is expensive; don’t let your fixed price lead to enhanced definitions of quality, “since it’s free.”
  • Be very clear on your responsibilities after delivery.  Ideally, it will be expressed in the SOW as a number of hours, over a period of weeks.  In any case, define up front when support begins, and when it ends.

Agile methods produce high quality results via iteration and refinement, but the iterations needn’t be endless. Agile projects can be managed to a cost target based on constraints such as time boxing and clear definitions of “done.”  The key is to be ruthless in enforcing agreed-to definitions of quality and completeness, and ensure your customer is holding up their end of the stick.

Getting Enterprise Software Development Requests from Speculation to Articulation

Posted on by
Reply

In my experience, most scope creep in enterprise software projects manifests as “feature-itis.”  This is the demand for some custom feature to be added to packaged software, by some stakeholder.  In many cases, the requested feature / behavior / report is required by some authority, internal or external, and driven by compliance.  These generally (but not always) qualify as “Must haves.”  In other cases, closer inspection reveals the request to be a variation of “We’ve always done it this way.”  These generally (but not always) end up in the business process re-engineering pile.  And in still other cases, it’s a desire for something completely new.  The stakeholder wants a capability they are currently living without, because they believe this project is an opportunity to get their wishes fulfilled.  When asked why they need this new capability, they speculate about what they could do if they had it.  Consequently, I refer to them as “If I had” requirements.

“If I had a boat, I’d go out on the ocean.

And if I had a pony, I’d ride him on my boat.

And we would all together go out on the ocean –

Me upon my pony on my boat.”  — Lyle Lovett

Now, don’t get me wrong: there are a lot of good innovations in the “If I had” category.  But things haven’t changed much since 2002, when Jim Johnson of The Standish Group noted that only 20% of software features are regularly used, and over 60% of features are rarely or never used.  Even today, most of the business value derived from any premises-based software or SaaS implementation comes from the most common or high-value-added use cases.  So it benefits the organization to focus scarce resources on those high-value cases.  That doesn’t mean we should stifle innovation; far from it.  We simply need to ensure the selection process is sufficiently rigorous.  And one the best tools for driving that rigor is enforcing the use of user stories, so common in Agile methodologies.

“As a <role>, I want <goal/desire> so that <benefit>”

Re-structuring the requirement as a user story forces a more specific articulation.  It also makes the proposal less about the person proposing the change than about a role.  This allows the proposed requirement to be better (and less emotionally) evaluated for business value.

  • Articulating the role helps drive the conversation about who benefits.  Will the beneficiaries be the people who will bear the incremental cost and risk?  If not, are their interests important to overall success?  I remember writing a massive audit report for one project that was run once and never used again, since the stakeholder left the organization and no one else cared.
  • Articulating the goal or desire helps drive the conversation about how to achieve it and keep it in operation.  The cost of delivering and maintaining the new capability is largely a function of the solution chosen.
  • Articulating the benefit drives the conversation about the business value that will be derived from this proposal.  Saving ten hours a week is significant, but at what labor cost?  If accuracy will be improved, what cost savings will be realized?

As practicing IT project managers, we want to guide our project stakeholders who are practitioners of other arts and sciences to effective solutions.  We don’t need to match their level of subject matter knowledge; we simply have to facilitate their ability to articulate their requirements.  Of course, I doubt Lyle Lovett could re-phrase his wish for ponies and boats as a user story, and even if he did, I doubt you’d want to sing it.  But some desires are better sung about than added to a development backlog.