Lecture 2 Developing a Strategy for Success

Lecture 2 Developing a Strategy for Success

Reading: Chapter 4,5 (Communication and Process)

•    Approaches to Managing Web Projects (Waterfall, Agile, Hybrid)
•    Introduction to Web Project Management – a 5 stage approach
•    Customizing a process to your needs

What you will learn in lesson 2:
1. What are the main approaches to Web Project Management?
2. A Five stage approach to managing a project
3. How organizations customize approaches to suit their needs and the needs of their sponsors

In the first week of class we reviewed a definition for Web Project Management and discussed five ways that Web Project Management is unique. We also discussed reasons that Web projects fail and how to avoid those failures.

Now we will examine some popular approaches to managing Web Projects and examine a common approach. The textbook gives just a brief overview of these different approaches. We will go into more depth. Then we will see how some organizations utilize aspects of different approaches to develop their own, customized approach.

What are the main approaches to Web Project Management?

There are a number of approaches to Web Project Management. The most common are:
1.    Traditional or sometimes called Waterfall
2.    Agile
3.    A blend of waterfall and agile for a custom approach

Traditional or Waterfall

Waterfall is the process tested in the PMP exam. It is a sequential process where each stage leads to the next stage. Typically one stage is not started until the previous stage is completed.
The project progresses like a waterfall, never traveling back a stage but always progressing to the next point.

Project Management originated in the construction industry where it is essential you know what will happen at each stage of the project so you can order the correct materials and know which skilled labor to bring onto the project at which time (yes that is right – the ancient Egyptians were the original Project Managers.)

1.    Distinct phases make it easier to know what is supposed to happen at each stage
2.    You can document a plan and then get agreement on the plan before you continue
3.    Is designed to deliver projects by a set launch date and within a set budget
4.    Changes in this model, once the initial plan is approved, delay the launch date and can increase the budget. Change is therefore avoided.

A Sequential or waterfall approach is most appropriate for design firms in which clients require a specific launch date be set and adhered to and where there is no flexibility in the budget.

In a waterfall approach, changes to the plan require work to be redone, costing the firm additional work hours which increases labor costs and lengthening the time to complete work which extends the launch date. Small clients often need to know exactly how much a project will cost and demand a design firm stick to the original quoted cost. If the design firm agrees to a change, the costs are either absorbed by the design firm or are paid for by the client over and above the approved budget or else, something must be eliminated from the original plan in order to have the time and pay for the cost of the change.

A typical waterfall process

The Project Management Institute is one of the largest associations for project managers. On their website they state they have “more than 650,000 members and credential holders in more than 185 countries.” [http://www.pmi.org] It certainly is one of the main associations in the US. If you talk to someone in the UK they may be more familiar eith the Association of Project Managers (APM) [www.apm.org.uk/ ] Let’s take a look at the PMI’s Body of Knowledge (PMBOK) in which they describe their approach to project management.

The PMI breaks the Project management processes into five groups: [http://www.pmi.org/en/About-Us/About-Us-What-is-Project-Management.aspx]
Project management processes fall into five groups:
•    Initiating
•    Planning
•    Executing
•    Monitoring and Controlling
•    Closing

This is a very typical waterfall type approach. One of the things that the PMI is known for is the PMP (PMI Project Management Professional ) certification process. In order to qualify for the certification a candidate must demonstrate that they have classroom experience, practical work experience and that they have passed the PMI’s PMP certification exam. Once certified the PMP must continue to take courses and earn 60 PDU (Professional Development Unit) credits in three years to maintain their certification.

Since its founding the PMI has branched out to offer a number of certifications in related project management areas. These certifications have similar requirements and some project managers go on to be certified in several areas.

It is not necessary to be certified in order to be a Project Manager, although some organizations, especially large corporations might require a PMP certification. The certification process and PDU requirements is expensive. Most Web Project Managers do not need the PMP certification, although they do need to stay current with the latest developments in Web project management.


Software development typically involves working with large programs with many lines of code. The waterfall method grew cumbersome as software projects grew more complex until developers reached the point that the program needed to updated before the release date. Software developers began to make adjustments to the waterfall methodology in search of something that could help them turn out software more quickly.

In 2001, a methodology that had been around since the 1950’s emerged when a group of programmers sat down and wrote up a simple manifesto and 12 principles for a more flexible approach to development. [Agile for Dummies, page 6 – 9.)

As more and more software teams experimented with Agile principles, the approach grew in popularity and the approach has been used with more and more complex projects and extended to other areas including Web applications.

The basic idea of Agile is that the Web team works closely with the client on a daily basis. Based on feedback the team and stakeholders create short-term goals, meet for feedback and then decide as a group on a new iteration or new goals. Change is not to be avoided as in waterfall but embraced and accommodated for in order to keep the project current and relevant.

Agile teams have different designations for the various responsibilities involved in running an Agile project.

In “Agile for Dummies,” by Scott W. Ambler and Matthew Holitzer, Agileis described as deemphasizing “specialized roles.” All team members are considered equal — everyone works to deliver a solution regardless of their job. With the exception of stakeholder, everyone’s effectively in the role of team member.” page 11.

Team members have roles such as:

  • Product Owner
  • Team Lead
  • Architecture Owner
  • and secondary roles such as:
  • Domain expert
  • Specialist
  • Technical expert
  • Independent tester
  • Integrator

Waterfall vs Agile

Waterfall requires all the planning, risk assessment and contingency plans, launch dates and budget be decided before the project is started. Changes are avoided as much as possible because they can delay the project. Web projects are often much less complex than traditional software programs and so the complexity is not as big an obstacle as with huge software projects.
Waterfall is a good solution when:

1.    The stakeholder requires a specific launch date or their organization will be adversely affected. This might be when coordinating a launch with a marketing campaign or an event registration announcement.
2.    Changes are arbitrary and can easily be moved to a phase two without causing the project to be adversely affected and without causing any damage to the stakeholder’s strategy or goals.
3.    Stakeholders are often very busy and do not have the opportunity to meet frequently with the Web team.

Agile is a good solutions when:

1.    The Web project involves a complex project that will require a lot of development work over a long period of time
2.    The development team will be working in an environment involving frequent changes due to the inability to predict project requirements at the beginning of the project or during the project
3.    Stakeholders who are prepared to meet often with the development team and be available to provide frequent feedback throughout the project that is designed to be an ongoing process
4.    Stakeholders who are not limited by a fixed budget but are willing and able to hande the unpredicatable nature of expenses arising out of the series of short development stages required by agile
5.    Agile does best with a development team that does not change over time

If you plan to outsource a Web project to a design firm, think about which approach would be the best approach to your needs before choosing a firm as many firms specialize in one or the other process. Make sure the vendor you select has good reasons for matching their recommended approach to your requirements. If the firm recommends using an agile approach verify that they have experience with agile and talk to their references. Agile is relatively new and you want to make sure that the firm you use has considerable experience with agile or you could find the project costing more and taking longer than you desire.

Custom Approach – 5 Stage Waterfall with Agile concepts

Most in-house and design firms don’t follow the PMI’s which they find too cumbersome. They don’t implement a strict agile approach because their clients require set deadlines, aren’t available for frequent meetings and insist on a set budget. Instead, more and more Web teams are customizing waterfall with agile concepts. A customized approach for a Web design firm is described in “Interactive Project Management” textbook. This is an example of a waterfall method that utilizes some agile concepts. This is by no means the only or the best way to develop a method that works best for your organization.

Many things happen simultaneously in during the Web Project development phase. The textbook is very good about showing all the different aspects involved and the different types of skill required to complete the project. However, it easy to get lost in front-end and back-end descriptions. If you are just starting to use Web Project Management techniques, the information can be a bit overwhelming. Here is a simpler view of the project process identified in “Interactive Web Projects.”

Project Definition -> Project Production  -> Project Staging ->Project Launch -> Project Closure

Project Definition

Each of the five phases has at least one or more stages. I like to combine to Project Prep and Project definition phases together and treat the project prep as the first stage of the Project Definition, unlike the textbook. During the Project Prep stage we are gathering the information needed to define the project. As the book indicated much of the Project Prep stage is getting to know and understand the client. If you are an in-house Web Project Manager you may already know the stakeholders well. These would be departments that issue many project requests, such the marketing team. Other stakeholders might be heard infrequently – such as the Finance department. However, don’t let familiarity breed complacency – it still pays to sit down with the stakeholder and get a good idea of why they need the project and what they hope to accomplish.

On occasion an in-house stakeholder will assume the Web Project Manager knows all about their operation and needs. This is the time to avoid assumptions and ask many of the same questions you would ask if you were creating web projects for an outside client. The difference is you may get some pushback from an internal stakeholder wanting to know why you are asking questions you should already know the answers. This can be a touchy subject since many people outside the Web division may already think that Web Project Managers just slow things down by documenting every tiny detail in Microsoft Project.  Be sensitive to this issue. Explain at the beginning of the meeting that while you are familiar with the department you will be asking questions to verify your understanding of their needs and to make sure their strategies haven’t changed since the last time you worked with them. (If the new project is an extension or phase two of a recent project, you might not need to bring up questions the stakeholders have already answered. Use your judgment.)

While you are gathering information about the project, you will probably be getting ideas concerning strategy goals. This is why I like to view the Project Prep as the first stage of the Project Definition Phase, however, it is a good idea to resist the temptation to cut the Prep stage short and jump right into the definition. You don’t want to get into the middle of your project and then discover some important information that has major implications for your strategy.  Take the time to gather all the details before beginning to create your plan and recommend solutions.

One of the nice aspects of the approach offered in the “Interactive Project Management” book is the Web Project Manager takes the time to understand the reasons behind the project and develops an approach that specifies a strategy for achieving the goals of the project before the cost of implementing the strategy is presented to the client. Note that this is a two step billing process: 1) a cost is quoted for the Project Definition Phase (another reason I like to include the Project Prep stage into this phase.) This covers the time needed to determine gather the information needed to make the project.

If a design firm quotes a cost for the entire project before they know what is involved, they will probably face a more complicated and costly project than they anticipated. Then they will either 1) have to charge the customer more or 2) have to take a loss or 3) have to convince the customer to leave out or move features and/or content to a subsequent project.

None of these options will enhance the reputation of the Web firm.

If you are an in-house Web Project Manager you also face a dilemma. If you don’t “train” your internal departments to expect and appreciate the information gathering stage, you too face the prospect of finding mid-way through the project that some important goal was never mentioned, perhaps because the stakeholder just “assumed” you would know that this goal should be included. Even if you aren’t in a position to charge for your internal Web team’s work, you still want to go through the information gathering stage.

Here is a tip for in-house Web Project Managers: always prepare an “Market Value Assessment” of the project. I don’t deliver this during the project, but wait until the project is complete. Then I include the estimate of the market value of the work the Web team did for the stakeholder. This lets them see that this “free” work has value and can help diminish the idea that the Web team is a “cost center.” It is amazing how many times you run across someone like the VP who once told me, “I don’t see why you need project management skills to develop this interactive video project – after all, it’s just HTML, isn’t it?” So, estimate the value of the project and let your stakeholders know that your team’s work is valuable.  If you are really fighting the outsource vs having an internal team battle, go ahead and get a couple of outside firms to bid on the project to show just how much your team is saving the organization.

Project Production

The Project Production stage for an in-house Web Project Manager is identical to the work facing the agency Web Project Manager. Some agencies believe that in-house Web Project Managers don’t need to think about budgets, but in many ways this is even more important to a department where the budget you work with is approved by your boss or your bosses’ boss. There isn’t a project manager around that doesn’t have to consider the impact on the budget with every decision.

During the Project Production phase the project is being built based on the specifications created in the Project Definition stage. As the Web team conducts this work, the Web Project Manager needs to be on the lookout for assumptions that were made but not realized during the definition stage, and for lessons learned.

Every project has some unique elements and there will be some false starts during development. Capture these in a Lessons Learned document and during the closing stage revisit these with the stakeholders and Web team in order to recognize and have a plan to either avoid them (if negative) or use them to improve the process on the next similar project.

Project Staging

The Project Definition stage is fun. Everyone is excited to have a new and challenging project to work on. The Project Production stage is equally exciting as finally, after all the talking and planning and research, it is time to build something!

The Project Staging stage is where the stress hits. Typically, it is not so much fun, however it is the most important part of the project. This is the stage where everything can and often does go wrong. This is the point, as the textbook suggests, where the designer and the programmer may face-off as to whose fault it is that something isn’t working. I told you so’s get thrown around a lot. Zealous testers get on everyone’s nerves with their bug reports and clients or stakeholders can bring everything to a halt with a single objection or change in goals.

This is the stage where the Web Project Manager earns their keep because they are the one who has to keep everyone talking to everyone else. They must negotiate between competing views regarding whether a user interface option is a bug or a feature. They must work to come up with imaginative ways of accommodating last minute changes and still keep the project on track for the original launch date and stay within the approved budget.

If neither of these prove possible then it is the Web Project Manager who must get permission to launch late or go over budget. Sometimes, permission is not the correct word – at times the Web Project Manager is the bearer of the unwelcome news. It is not a conversation that any Web Project Manager wants to have and it is one a great Web Project Manager will work hard during the Project Definition and Project Production stage to avoid.

In small firms and at marketing driven companies Web Project Managers can face a tremendous amount of pressure to shorten or skip the testing process. This is never a good idea and those Web Project Managers who agree to conduct little or no testing find themselves in the difficult situation of explaining how a typo or a feature that doesn’t work got into the launched product undetected. In many ways, a Web Project Manager’s reputation depends on how well they resist pressure to eliminate the testing phase.

Project Launch

The Project Launch can feel like a final plunge down a rollercoaster ride. Everything seems to happen quickly. That is why it is so important for the Web Project Manager to anticipate what will happen, what could happen and to have a plan for dealing with the unexpected.

As the textbook emphasizes, Communication is key during this time. While the focus in large part during the Project Production phase was to maintain communication between everyone on the Web team, the focus during the project launch is communications with the team and the stakeholders. If your relationship with the stakeholder or client hasn’t gone well up until now, the problem has the potential to escalate during the launch phase.

Clients/stakeholders are going to be under a lot of pressure themselves during the launch. For many in the organization, this may be the first time they see the new project on the Web. Everyone has an opinion of what “should have been included,” in the project. Your client/stakeholder contact is getting that helpful advice/criticism in spades. Depending on their personality, they are handling this well or not so well. This is another reason testing is so important. Simple bug fixes and typos and features not working only add fuel to the fire that the new Website is not as good as the old. (Often, stakeholders are attached to the old Website.

If you are doing a redesign with a new interface, new look and feel, the way to make sure you don’t get a knee jerk reaction against the new site is to make sure everyone in a position of influence has seen the new design ahead of time and had an opportunity to comment on the new design. Designing by committee leads to poor design and functionality, but, commenting on a design, is not designing. It is providing you and the client the opportunity to explain design choices to everyone. Listen closely to these project definition discussions – they often lead to the most innovative features on a new site.)

Pay close attention to the section in the book on training the client/stakeholder. The most common complaint expressed against a new site design is, “it looks great but we can’t update it easily.”  This is why having the talk about how the site will be maintained in the definition stage is so critical. Also, clients love manuals. They are like security blankets. It is all very well to be sitting in a training room clicking merrily along while someone tells you to where to click. However, when you get back to your company and everyone is looking at you to answer every question, your mind can go blank. That is why clients love manuals. They can refer back and refresh their memory on just how you imbed a video file in the CMS template!

Commit the Launch Day Plan to writing and then give everyone a copy. Go over it ahead of time.

Here is one thing you don’t want to do – do not announce the exact time and day of the launch ahead of time, especially if the organization has a following. One event organizer thought he would be clever and announced that the first twenty-five people who signed up on the new Website would win a special meeting with the keynote speaker. He announced the exact time that the new site would be launched. Except the site didn’t launch because the server couldn’t keep up with all the hundreds of people who hit the site the minute it launched. The site crashed and the big launch was a disaster as frustrated registrants tried repeatedly to signup only to create an even bigger load on the server. Launch, then open registration. Let’s repeat that: launch, then open registration, preferably a week or so later when you have any and all potential issues cleaned up.

Project Closure

If a Web team is going to get better then the Web Project Manager needs close the project by holding the post-project team meeting and reviewing what went well and what could have gone better with the project. If you are working with an design firm or an agency you may find over time that the type of customers and/or the type of projects you are dealing with have many similarities. This is both a blessing and a curse. A blessing because your experience will help you get very good an anticipating issues, testing assumptions and accurately predicting estimates. A curse because it is easy to get complacent and start to think all the projects are going to be the same and not do the rigorous discovery each  project deserves. In fact, this can be an even bigger danger if you are an in-house Web Project Manager. It is too easy to assume the environment is unchanging and ignore a new competitor, or new regulation or new technology that might have a major impact on your project.

Reviewing each project will alert you that conditions are starting to change and provide an opportunity for you and your team and/or the stakeholders to discuss the change. This can of course, lead to a new project, but with new challenges come new opportunities.

An important function of the Project Closing Is to provide the opportunity to finish completing all documentation related to the project. Meeting notes, lessons learned, etc. should be included in the file. Some of this information will be in electronic form, but keep a hard copy of all documents requiring signatures.

Customizing a Web Project Management Approach to Fit Your Organization’s Needs

Agile is a methodology based on a set of principles. Scrum is an implementation process, a set of rules. There are several implementation approaches to Agile. Scrum is probably the best known.

As we learned earlier, under the right circumstances, Agile might the be perfect solution for your Web team and clients/stakeholders if you deal primarily with:

  • Complex projects
  • Clients/stakeholders able and willing to work closely with the Web team
  • A flexible budget and a non-specific delivery date.

If your projects typically are not very complex and have strict launch dates and budgets, you can still benefit from utilizing some Agile philosophies and scrum rules. Here are some that you might find helpful in customizing your Waterfall process to better suit your needs. Many intuitive Web project managers already have incorporated some of these ideas into their management practices and may be surprised to find they are already customizing waterfall with aspects of the Scrum approach.

1.    Team collaboration – Agile emphasizes team members and customers collaborating with each other. Any Web team will work best when ideas are discussed and the team reaches agreement on the approach to take rather than an executive or Web Project Manager dictating tasks to individual team members and keeping the client in the dark about the development process until the Web project is completed.
2.    Morning Meetings – Daily meetings are also a principle of Agile development. Although many people cringe at the idea of meetings, a Scrum technique is a 5-10 minute meeting of the entire team. Each member announces what they accomplished the previous day, what they will work on that day and obstacles that might block progress. Using this approach, the entire team knows what everyone has accomplished and is working on and may offer ideas on how to overcome road blocks.
3.    Project Review – Scrum is known for breaking a project down into smaller subsections, known as “sprints.” When a sprint is completed everyone associated with the project meets to review what has been accomplished to determine if the goals for that sprint have been achieved.  Period review meetings with the Web team, stakeholders/clients are a good idea and help verify that the project is on track, allowing for corrections to be made once the project has started. Notice in the textbook, the authors discuss how they allow for changes to the original plan but limit the number of iterations. Building in flexibility for changes, but limiting the number of changes is a compromise between the traditional approach of avoiding changes at all costs and agile’s approach of managing change by allowing change throughout the process.

What you learned in lesson 2:

1. The best known approaches to Project Management are waterfall or traditional project management and Agile.
2. A Five stage approach to managing a Web project is:
Project Definition -> Project Production  -> Project Staging ->
Project Launch -> Project Closure
3. You can customize waterfall with scrum strategies to introduce agility into your waterfall approach

ASSIGNMENT: Describe your current process and how it might be approved. If you don’t have a current process, specify which process would be most appropriate for your organization.

Leave a Reply