You know the feeling.  You’re finishing the kickoff meeting for a new project.  All your stakeholders are smiling having just seen your project plan and schedule, and they’re filled with confidence that, thanks to you, their project will be delivered on time and on budget.  You’re not quite so sure.  They don’t seem to understand that those dates you presented were estimates (dare we say guesses), that all participants have imperfect and incomplete knowledge of the requirements, and that a great deal will likely change before the project is complete.  This scene is played out repeatedly in firms of all sizes.  And I believe it illustrates the core challenge of project management; the tension between the reality of uncertainty and a desire for predictable outcomes.

Over the past 10 years, several new project management methodologies have emerged that attempt to do a better job of reducing that tension by providing a more flexible approach to achieve desired project outcomes.  These are generally referred to as "agile" methodologies and include Crystal Clear, Rational Unified Process (RUP) and Scrum, to name the most widely used.

Agile methodologies arose from a growing understanding that traditional project management approaches tended to be at odds with the way firms operate in several important respects.  The following highlights some of the characteristic differences between traditional and agile approaches:

• Traditional
  Requirements are assumed to be known up-front and held constant until completion.  A "change management" process is required wherein change is the exception, not the rule.
• Once requirements are set, the project team is free to determine the order of work to suit their needs.
• It’s assumed that until all work is complete, the firm won’t realize the benefits of the project.  Some interim benefits may accrue, but this is a happy accident, not a planned outcome.
• Progress is reported through formal mechanisms such as status meetings and Gantt charts, which are often confusing for stakeholders.
• Agile
  Change is assumed and mechanisms for frequent course corrections are provided.
• Work is performed based on stakeholder-driven priorities.  Stakeholders decide what gets done; project teams decide how to do it.
• Focus is on completing work incrementally, providing a smoother stream of benefits to the firm.
• Feedback to stakeholders is provided via frequent meetings (every 2-4 weeks) so they can adjust priorities to meet changing understanding of requirements and business needs.

At Fenwick & West we’ve adopted (and adapted) the Scrum methodology, which takes its name from the term for a huddle in the sport of rugby.  Like all agile methodologies, Scrum has its roots in software engineering, in which there tends to be a high degree of uncertainty with regards to methods and requirements.  But there is no inherent reason why this methodology cannot be applied to any type of project.  At the heart of the Scrum methodology are the beliefs that:  (1) completed work should be delivered in rapid iterations; (2) frequent communication with stakeholders is critical; and (3) requirements will change.

How We Do It
Let’s look at how this works in practice, taking Fenwick & West’s project to deploy a new business intake system as our example.  It’s important to realize that while a two-week cycle is repeated throughout the project, the emphasis in terms of deliverables tends to move from the general to the specific as the requirements come into sharper focus.  For example, early deliverables in this project included lists of required data elements or report prototypes, while later deliverables addressed specific features or enhancements, such as determining which fields’ data to write to the billing system or adding a billing attorney notification.  This two-week cycle provided us with a project "heartbeat" that promoted communication, learning and a focus on delivering the most important work first.

Every two weeks we met with our principle stakeholders, or "internal customers," to present completed work and to review the list of pending deliverables that had been defined but not yet completed.  First, our stakeholders were asked to accept or reject completed work, with rejected work being returned to the pending list.  Then, pending deliverables were prioritized in order of value to the stakeholders so the project team could select the most important for completion during the upcoming two-week cycle.  What we didn’t discuss was the status of incomplete work, which, prior to this meeting, the project team had placed back on the pending list for reprioritization.  In Scrum (to paraphrase Star Wars’ Yoda), "work is either done or not done, there is no try."

At the end of this meeting, both the stakeholders and the project team had a clear understanding of the pending deliverables and the relative value the stakeholders placed on each of those deliverables.  The project team could then assign work for the new cycle, confident we knew where to focus our attention.

Immediately following the stakeholder meeting, the project team convened to "divvy up" pending deliverables, drawn from the pending list in priority order, until each team member felt he had as much work as he could reasonably expect to complete during the upcoming cycle.  A key point here is that work was assigned using a "bottom-up" approach, which fostered more realistic workloads and greater individual buy-in.

Each day during the two-week cycle, we held a Scrum meeting (or "huddle") during which each team member answered three questions about their assigned deliverables:  (1) what was accomplished since the last huddle; (2) what did they expect to accomplish before the next huddle; and (3) what assistance was required from other team members.  The point of these daily huddles, which usually lasted only five to ten minutes, was to prevent bottlenecks by keeping communication flowing among all team members.  Throughout the two-week work cycle, our stakeholders were available to clarify deliverables but were not allowed to reorder priorities or insert new deliverables into the project team’s "in process" list.  This allowed the project team to avoid the productivity drain that comes from frequently shifting priorities, and such a restriction was feasible because of the relatively short duration of each cycle.

At the end of each cycle, just before the next meeting with stakeholders, all in-process deliverables were flagged as either complete or returned to a pending status for reprioritization, and the cycle repeated.

This brings us to a note on technology.  None of what’s described in the Scrum process requires more than a simple list to track deliverables, status and responsibility.  At Fenwick & West, we use a SharePoint list for this purpose, but Excel would work just as well.  The purpose of any project management technology is to promote communication.  If your technology requires special training to use, you run the risk that not everyone involved will have the same understanding of the direction, priorities and status of the project.

The Scrum project approach contributed to the success of our new business intake system by promoting communication, responsibility, knowledge transfer and trust.  It helped make project priorities very tangible and allowed the project team to deliver the most valuable results first.  It also provided the necessary flexibility to adjust course as early deliverables and feedback from beta testers resulted in changes to our understanding of the business requirements.  The end result was a system that received high marks from both stakeholders and end users.  I attribute this success, in large part, to the dedication and skills of the stakeholders, beta testers and project team.  But underpinning this was a methodology that promoted communication, flexibility and trust.

In my experience, the most often-raised concern about Scrum or other agile methodologies is how the lack of a fixed schedule and fixed set of deliverables at the outset will impact final target dates.  When stakeholders have committed to completing a project by a certain date, it may take some work to convince them that an agile approach will deliver more results in less time.  We all tend to prefer the illusion of certainty, while agile methodologies assume and embrace uncertainty.  This concern can usually be addressed, however, by pointing out that Scrum provides stakeholders with more frequent and direct control over a project’s direction, deliverables and priorities.  The stakeholders’ perceived need for certainty is reduced by the belief that there will be a real increase in flexibility and control.

One other key issue that can impact the success of any project is the willingness of stakeholders to stay engaged.  Scrum requires frequent participation by stakeholders, some of whom might prefer that the project run on autopilot after the kickoff meeting.  Although absentee stakeholders can derail projects using any methodology, Scrum, for better or worse, makes their inattention highly visible.  On our new business intake project, we were fortunate to have highly engaged and supportive stakeholders, but it is always wise to "guard the exits" carefully on any project.

Worth Its Weight
The Scrum methodology has proven its worth at Fenwick & West, helping us to deliver high-quality outcomes on both internal and client-facing projects.  While each project is unique, the common characteristics that Scrum promotes are open communication, a shared understanding of both project priorities and implementation trade-offs, a more realistic schedule, greater trust and reduced stress.  In a world where 67 percent of projects are reported as outright failures, that’s not bad.

About our author :: :: ::

Mark Gerow is the Manager of Application Development at Fenwick & West LLP.  He has more than 20 years of experience in IT professional services and software product development.  Mark is responsible for the firm’s intranet, extranet, collaborative and applications development initiatives.  He has also written extensively on the use of Microsoft SharePoint for publications such as ASP Today Online, SharePoint Advisor and LAW.COM, and he is the author of the book "Creating Client Extranets with SharePoint" (Apress).  Mark holds degrees in computer science and economics, as well as an MBA.  He is also PMP certified.  He can be reached at mgerow@fenwick.com.