by Carl Sutter
CrownPeak Technology
PM Boulevard
March 2002

Let’s face it:  IT project managers will often not win votes as “Most Popular” and rarely are even considered “Likely” – let alone “Most Likely” – to succeed.  Projects get bogged down under mounds of specifications, proposals, requests for approvals, change orders, progress reports and meeting minutes – none of which helps you complete your project, and all of which distracts you from your ultimate goal. 

This is not a new problem, and it isn’t unique to IT.  But there is a solution, specific to our industry, which at first glance seems to contradict everything you’ve learned about planning.

Build first, fix later. Technically, it’s called Rapid Development. 

As a veteran specializing in online content and asset management systems, with 6+ years of frontline experience building and integrating content management systems (CMS) for Global 3000 companies, I’ve observed two general methodologies used in web project management – Long vs. Rapid. 

• Long Methodology involves creating a detailed, (phone book sized) functional specification and reviewing it point-by-point with your team of experts and a host of participants from your or your client’s organization.  This approach makes sense when you are building a large custom application (since changes to the code can be quite costly), or using a well established technology (since the capabilities and effort are more easily specified).  Advantages to the long methodology include:
  Certain aspects of a large custom application need to be designed a priori, such as the database schema.
• You’re able to obtain client approval before implementation, assigning responsibility and identifying a cost basis for change orders.
  
• Likewise, this approach helps assure adoption and that individual needs are met within a company.
  
• It also helps compensate for individual design weaknesses.

There are, however, several problems with this approach.  Clients usually have difficulty interpreting the conceptual functional spec, especially when it comes to the interactive nature of the application.  Indeed, all too often clients don’t even bother to read the entire document.  They either sign off on something they don’t understand -- waiting until the implementation stage to raise questions and request changes -- or they stall the process while the spec sits, unread, under a pile of paper on their desks. 

Other challenges intrude.  Functional specs often state assumptions and exclusions, but don’t detail the implications of those assumptions.  Programmers also routinely uncover functionality during development that wasn’t fully addressed during the specification phase, and cannot be implemented within the authorized budget.  Functional specifications can vary widely in quality, so project success is not assured.  And, finally - one of my pet peeves - the specification process typically involves more staff than needed for simple decisions (an entire mixed team may often discuss a single data field layout that one designer would have set up right the first time), causing delays and conflicts that should have otherwise been avoided.

In short, no matter how thoroughly and efficiently project managers prepare specifications, there will likely be costly, time-consuming changes down the road.

So why not welcome them?

The rapid development methodology – where you build the application quickly, then refine – is based on the highly technical “If you can’t beat ‘em, join ‘em” philosophy.  You know you will encounter changes throughout implementation, so why not design your process around them?  An experienced developer’s “best guess” at what the client will want, or reuse of existing project components is often a better starting point than a blank sheet of paper.

Rapid development is not a new concept (extreme programming etc.), but becomes even more relevant with the upcoming generation of Internet applications.

In most situations, you will increase your chances for an on-time/within budget success using this methodology:

• Gather as little basic information as necessary using a well-designed but minimal set of questions
  
• Build fast, using a library of tested interfaces (usually, a one-to-two week process
  
• Internal production review: collect feedback and incorporate changes
  
• Burn-in: Give access to client, collect feedback from a carefully selected group of participants and incorporate changes
  
• Launch

Using this process, it’s possible to complete a project within a single month.  Rapid methodology alters the early phase client dynamics from an consultative relationship to a well-defined, goal-oriented approach.  I’ve found it works much better to say up front, “We’ll have four meetings: one to kick off, one for follow-up questions, one to hand over control for burn-in, and one to finalize launch.”  Projects get managed and completed without the need for weekly status meetings, “phone book" authoring and micromanaged decisions. 

Rapid development makes sense when you are working on a configured application, a developer environment that is easy to change, or a small application.  This approach may also be well-suited to emerging technologies, since the capabilities of the development environment are explored alongside the prototyping. 

Rapid development is successful because:

• Much of the prototype becomes the final project, saving a great deal of time.
  
• Opting to not write a large functional spec similarly saves an enormous amount of time.
  
• Clients are able to visualize the application’s function – and make changes based on something they can “touch,” not a conceptual specification.
  
• Users get a hands-on feel for the interaction of the application – and can request changes without significant cost overruns.
  
• Time spent on project management is significantly reduced.

Of course, there are some disadvantages as well.  Cost savings are assumed, making projects that suddenly turn out to be larger than anticipated more difficult to complete.  For large development projects, prototyping all of the potential interactions can be exceedingly difficult.  Also, many clients are accustomed to the level of involvement and mounds of paper they get with the long methodology, no matter the inconvenience and wasted time.  The rapid methodology’s more condensed (and sometimes less formal) process can leave some organizations wanting for meetings and explicit “buy-in.”

Challenges and Best Practices For Rapid Development
Whether or not you choose to adopt the rapid development methodology, some best practices can apply across the board to increase project management success.

• Challenge:  Client who has trouble understanding technology and wants a lot of explication.
  Clients who have trouble understanding technology usually are more comfortable with the process if they can see something and provide feedback on the actual product.  Most of the time they cannot visualize the specification you provide on paper.  The energy you spend developing that spec and interpreting it for your client could be better spent developing and reviewing an actual prototype.  Your client will feel more comfortable and you will progress more rapidly toward project completion. 

• Challenge:  Client who wants to specify the system in great detail.
  It’s axiomatic that clients who micromanage provide a whole new set of challenges.  These clients are used to being involved in every step of the process, usually expecting regular status meetings and participation in every decision.  This type of client relationship bogs down the development process, making it anything but “rapid.” 
  Try to limit the number of meetings from the beginning by including meeting dates and time limits in your contract.  (Hint: to keep your meetings short and to the point, don’t provide chairs.)  Know the system well and keep it flexible enough so that changes can be made quickly and easily.  This enables your clients to remove themselves from the day-to-day project management while trusting that you will indeed make any necessary changes to ensure that the outcome is exactly what they need.       

Other tips:

• Keep standard system specification forms ready, but don’t send them out unless absolutely necessary.
• Develop very rapidly so your client has something to see quickly.
• Make sure your client understands all the options for changes and ongoing support.
• Have a burn-in period to receive suggestions – this takes pressure off the “launch and walk away” tendency.
• Avoid meetings with the entire user base – limit interactions to client contact (project owner or lead).  A possible exception: a major presentation upon rollout or at start of burn-in.
• Try to limit demos to user until system is ready – doing so avoids the perception of complexity since user fine-tuning usually comes at end.

The project management methodology you choose obviously should be based on the specific needs and goals of each individual engagement.  But more and more the rapid development process is proving an efficient and cost-effective way to see projects to completion – on time and within budget.