Tag Archives: Scope Creep

New PM Articles for the Week of July22 – 28

Posted on by
Reply

New project management articles published on the web during the week of July 22 – 28.  We read all of this stuff so you don’t have to!  Recommended:

  • Angela Workman-Stark recounts how the Royal Canadian Mounted Police learned to manage and drive change, after initially failing.
  • Elizabeth Harrin reflects on a heat wave, re-purposed artifacts, and the laundry, all on her first day back to work from maternity leave.
  • Scott Berkun recaps chapter 8 of his book, “Making Things Happen,” on how to make good decisions as a project manager.
  • Bertrand Duperrin observes an interesting side effect: effective collaboration reduces the number of workers needed for success, thus killing jobs.
  • Cyndee Miller comments on a report from The Economist’s Intelligence Unit, sponsored by PMI, called “Why Good Strategies Fail.”
  • Craig Brown suggests maybe we just need to simplify our strategy and focus on the main thing.
  • Will Kelly summarizes what has changed in PMBOK5, and what it means to those taking the PMP exam.
  • Glen Alleman offers some reading material on software cost estimating.  Actually, it’s a whole reference shelf.
  • Gary Nelson warns that zombies may be invading our projects.  But there’s a cure, and it doesn’t involve violence.
  • Ellen Gottesdiener explains how to manage scope as you discover requirements.
  • Martin Webster covers the basics of how to write a project plan.
  • Mike Griffiths considers the fine balance between planning away uncertainty, and executing away uncertainty.
  • Barbara Shannon tells us how to make people love our projects, by limiting the number of them.
  • Shim Marom raises the ethical question, “Are truthfulness and project management mutually exclusive?”
  • Neil Killick considers the ethics of letting his team fix bugs they didn’t create, at the expense of the work they’ve been asked to do.
  • Bruce Benson argues that your “best people” may not be the ones loudly finding fault with everyone else.
  • Andy Jordan addresses the question: how do you determine the value-add of your PMO?
  • J. LeRoy Ward notes some studies that indicate organizations with a lot of PMP holders tend to have more successful project outcomes.
  • John A. Byrne lists ten tough questions that interviewers at the Harvard Business School MBA program are asking applicants.
  • Jorge Valdés Garciatorres advocates the art of active listening.
  • Kerry Wills has some opinions on what makes for an effective EMail.  Mostly, it’s brevity.

Enjoy!

New PM Articles for the Week of July 1 – 7

Posted on by
Reply

New project management articles published on the web during the week of July 1 – 7.  We read all of this stuff so you don’t have to!  Recommended:

  • Andy Jordan gets back to the basics on PMO’s.  Most important: why do you want one, and what do you expect it to do?
  • Elizabeth Harrin offers some advice to entry-level project managers in the UK – CAPM or Prince2?
  • John Laverick reflects on the impact of the recent influx of “new” contract project managers in the UK market.
  • Patrick Richard summarizes his observations on the #NoEstimates movement.
  • Craig Brown summarizes with conversations over beers with Neil Killick on #NoEstimates.
  • Glen Alleman lists “an immutable set of questions that needs answers before we can determine the probability of success for our project.”
  • Ken Hardin looks at reviewing the current-state for risks, prior to starting a new IT project.
  • Tristan Wember has summarized and provided links to his recent series of articles on risk management.
  • Shim Marom is annoyed with the way the public discussion of project failure is presented.
  • Soma Bhattacharya has a few getting-started tips for her friend, an “accidental project manager.”
  • Tatyana Mishell shares an interesting infographic: “Four lessons in Project Management from the Renaissance.”
  • Jesse Fewell looks at a scenario for estimating in a release planning meeting for a program involving four Agile teams.  Note the excellent list of assumptions!
  • Johanna Rothman has published part four of her series on organizing an Agile program.
  • Chuck Morton recalls being in an organization that used the Microsoft Solutions Framework.  But not very well.
  • Pawel Brodzinski reports on the Kanban Leadership Retreat, and his presentation.
  • Bruce Benson argues that scope creep should be mandatory, especially for long-duration projects.  Should we call them “mid-course corrections?”
  • Bas de Baar offers an interesting alternative to culture engineering and driving change – play!
  • Linda Mitton sends in a report from the phishing pond.  Yes, you really need to be skeptical of every EMail!
  • Kerry Wills disses the cubical-dwelling co-worker who insists on using the speakerphone for every call.  Give ‘em a vasectomy discount coupon!

Enjoy!

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.