dyhatchett 's Library tagged no_tag →  View Popular

Step 3: Do We Really Need the Moon on a Stick?





In any exercise in gathering Needs, you're going to end up with a
mixture of must-haves, some should-haves, and some nice-to-haves.
You now need to split those three categories into two: Requirements
and Exclusions. Or alternatively, must-haves and everything else.
Every Requirement will be delivered in the project; everything else
will either be entirely rejected - either because it's not technically
feasible or the client won't pay for it - or deferred to a later
project or release.






Here's the Acid Test for which box each Need should go into:






1. 
   Is the Need part of the original intent of the
   project? An example of an Exclusion on this basis might be
   reporting sick days using the vacation tool.
   
2. 
   Was the cost of delivering the need included in the
   original estimate? Assuming that this has already been
   produced of course.

Step 2: What do you Need?





Now you've got a feeling for the context, you can start asking
questions (open ones, ideally) that will drive out what it is
that the sponsor needs. You'll also need to talk to anyone who's
affected by the project, or at least a representative of each group
to produce Needs for every major stakeholder.
You'll need some standard information for almost any project, such as:




• Why do you think we're doing this project?
• What's your role in the project and in the business?
• How will what we're doing affect your role?
• What functionality do you need?
• What would success look like for you?
• How do you define project completion?
• Which staff should have access to it?
• What hours must it be operational?
• How is an employee's vacation allowance calculated?
• How will we know if an employee leaves?
• What happens if an employee doesn't use all their allowance?





You should also be reading all project documentation - contracts,
proposals, statements of work etc - as these nearly always contain
strong hints of what stakeholders are expecting.

So step 1 is really Understand the Goals. How do you
do that? With luck, it'll be documented for you (and if it's not,
the old PM rule of If it's not documented, it's a rumour holds
true), but unless you enjoy working on assumptions, you talk to the
Sponsor and other key stakeholders (i.e. people who have an interest in
the outcome of the project). Useful questions to ask include:




• Why are we doing this?
• If we're successful, what would be the outcome for you?
• What would happen if we didn't do this project?

Deliverable by the designer alone:

Lossless archives of project assets:

Fully detailed snapshots:

Earlier identification of user experience issues:

Well defined scope:

Wireframes identify and locate all of a site’s significant elements, such as page headings, navigation, primary content, sidebars, and application interfaces. A single wireframe should be used to describe the basic layout of the entire site, but you should also create wireframes for section indexes and application interfaces.

Wireframes protect project participants from unpleasant surprises. They also provide the information needed to define the relationships between elements of site content, and the ways in which those relationships will be described in the site’s stylesheets.

Effective wireframes can also provide a focus for discussing the behavior of the site’s layout and interface, leading to resolution of any fixed-vs.-proportional, Ajax-vs.-static, and typography questions that remain open after scenarios are played out.

Armed with a detailed draft assessment, the team will know enough about the site to roleplay likely visitor sessions. Roleplaying will come naturally to some, and for the rest, it’s easy to explain.

Create at least one imaginary friend who bears a strong resemblance to the visitors you want to see on the site. Then create another imaginary friend (or two) whom you think would be likely to visit the site. If you want to be thorough, create one last imaginary friend whom you desperately hope will not visit, but who would still be in a position to influence others’ opinions of the sponsor if they did visit.

Since the assessment will have offered some hint of visitors’ likely goals, you can then roleplay visitor sessions. With each iteration of this process, you change different factors: user objectives, interface/architecture elements, common external obstacles, color use, themes, layouts, content weights, and so on.

Done properly, this step will establish the human factors of the design that will best suit the sponsor’s expectations. However, it can be expensive; effective scenario work generally consumes a dozen or so man-hours for a relatively simple site.

• Who do we want to visit the site?
• What are we publishing that those visitors will find important?
• Where are our visitors in terms of geography, ambient environment, and client platform?
• Why does the sponsor want the site built—what are its business objectives?
• When should the site be launched, phased, maintained, and finally taken down or redesigned?
• How are we going to build the site—what tools are we using, and what’s the budget?

• Assessment:

  A formal and detailed assessment of the project allows its scope to be properly defined.

• Personas and scenarios:

  Executed with care, scenario roleplaying identifies likely obstacles to positive user experience, which can then be removed from the design prior to signoff.

• Wireframes:

  The guidelines established by wireframes enforce layout consistency, discouraging the designer from composing everything as if it’s intended for print.

• Style guide:

  Adoption of a style guide allows collaboration between all team members to the end of finalizing the site’s design. Even clumsy execution of a style guide requires the graphic designer to “think out loud,” allowing needless edge cases to be caught and stopped before work begins on the prototypes of the work that will actually be put into production.

On many projects, I see the following process followed, and willingly follow it myself:





1. Acknowledge objectives
2. Design
3. Produce templates and stylesheets
4. Write code
5. Test presentation and behavior
6. Publish

• 0: Unengaged
• 1: Listening
• 2: Commenting and Connecting
• 3: Fully Engaged

3) Technology

Lastly, a Web Strategist needs to know how each and every tool and technology work, they’ll need to know the strengths, benefits, limitations and costs. This also applies to human capital, and timelines. Often technical limitations will reduce the scope of User and Business needs, so you’ll need to incorporate this going forward.

Skills: Software Development, Web Development, Web Architecture, Industry Trends, experiments with web technology, but understands how to extrapolate and harness a tool.

2) Business

The business sphere requires a strategist to understand the long term objective of a website and it’s goals. This sphere also requires ability to internally maneuver within an organization and maximize the persistent limitation in resources. A website that is not aligned to business or market objectives is ultimately doomed to fail. The User and Business requirements will often match, but will rarely ever be a perfect fit. The Web Strategist) will need to obtain business requirements from stakeholders, whether that be execs, sponsors, sales, or even shareholders. Understanding the market, competitors (and key milestones) and other external forces are also required –a business requirements model will be formed, these are your objectives.

Skills: Marketing, advertising, media, management, measurement, ability to evangelize internally, process management, resource management, obtain objectives, product development, product management, savvy in political maneuvering

Training Plans

If you are handing over the ongoing support and maintenance to another group, you need to arrange to give appropriate training for the team taking over the work. It's usually also worth providing documentation, so that inevitable personnel changes don't result in the new team members coming to you with questions months or even years later.

You should document everything that will need to happen in future for the site, from making content updates through to changing the design. You might also be expected to detail how the product was initially developed, what the underlying technical design looks like, and the design themes that should guide future updates. Again, this is an area where it's important to discuss expectations with your client; you might feel you've fulfilled all your obligations, but learn that they view the project as a failure because every incremental change renders your design less and less elegant, since those who inherited the site don't understand the overall themes.

Service Level Agreements

If you are going to provide the ongoing support and changes for the web site or product, then you will need to have an SLA in place. This document sets out the expectations for changes and support, including how quickly you are expected to respond to different types of issues; for instance, if the web site is unreachable or unusable, a faster response time would be expected than if there were simply a new page to be added.

Close-out Meeting

A close-out meeting is important to ensure that the project is finished to everyone's satisfaction. It should center around the original project initiation document, reviewing the milestones that have been delivered and evaluating whether the success criteria have been met. If decisions were made along the way (during issue resolution or stakeholder reviews, for example) that have resulted in a departure from the original deliverables and success criteria, then these should also be reviewed.

The outcome of a successful close-out meeting is that everyone is satisfied that the project is finished and that provision has been made for the future. Depending on the circumstances of your particular project, the latter will either center around a Service Level Agreement (SLA) or a training plan.

Figure 6. A progress update report

Progress Updates

Whereas stakeholder reviews are useful for making sure that those who have an opinion about the product you are developing are heard, progress updates are more to keep people informed of progress in the overall project. Keep this short and to the point: a good format has overall status at the top, sometimes using traffic lighting (red for severe issues, yellow for off-track, and green for on-track) if you are showing the status of several stages or milestones, with a more in-depth discussion of the specific achievements and issues following.

This means that those who just want to know how the project is going can just read the overall update at the top and can decide for themselves whether they want to continue reading to get the detail.

The other thing to consider is whether you are going to deliver progress updates over email, in a document, or in person. Discuss this with your client or internal customers, along with the frequency desired. You may find that only a monthly update is needed when things are going fine, but when issues are being encountered more frequent updates might be desirable.

Stakeholder Reviews

Stakeholder reviews are a mechanism for identifying and exploring differences of opinion. However much you and your team might feel that everything is going to plan, the project's stakeholders may disagree, whether it's the design they don't like, a key requirement they feel has been misinterpreted, or a missing feature.

By holding reviews with the key stakeholders, you can identify these issues early and decide whether or not a change in direction is needed. You can't realistically expect to achieve consensus all the time, but you can get the issues documented and the route forward agreed upon. Keep these reviews short and focused and hold them face-to-face whenever possible.

Figure 5. An increase in one quadrant results in an increase or decrease in the remaining quadrants

Balance Quadrant





The balance quadrant is a very useful tool when you're dealing with a number of requests to change the scope of your project -- adding extra functionality, for instance. There are four factors that are balanced in any project:




• time
• cost
• quality
• scope





The relationship between these factors is illustrated in Figure 4.

Issue List





An issue list is very different from the bug lists you're probably using already. Bug lists are about the technical defects you've found in the product; issue lists are about problems in the project itself. It's therefore worth keeping the two lists separate -- after all, the best person to fix the CSS padding bug is unlikely to also be the best person to negotiate a compromise between the marketing and admin departments so that the design can be finalized.





An issue list can have as many or as few fields as you need. You'll want to keep it lean so it's not a drag to keep updated, but still contains information to make it useful. Typically, I use an Excel spreadsheet kept where anyone can update it, with the following fields:




• date entered
• description
• owner
• status (open, in progress, closed)?solution
• date resolved

Risk Management Plan

There are risks to any endeavor, and web projects are no exception. In order to manage your risks, you need to first identify what they are, then rank them by likelihood and severity. It's up to you to decide where your threshold lies: you'll probably want to create a plan for dealing with those risks that are both likely and severe. You also want to determine how you'll be identifying whether a risk is becoming an issue, so that you know when to trigger your contingency plans.

Along with the project plan, your risk management plan is something you should definitely share with your client and key stakeholders. They need to understand what might go wrong and what you plan to do if these eventualities occur -- they might even have better ideas for how to deal with certain contingencies!

Important guidelines for planning include:




• Plan milestones, not tasks: It's very hard to measure how complete a task is, whereas a milestone is binary: it's either done or it's not.
• Break your milestones into small enough deliverables that you can track well: Aim to have mini-milestones small enough that one can be delivered every two to three days, without breaking down into nonsensically small portions.
• Assign each mini-milestone to one (and only one) person: Clear responsibility makes it easier to get stuff done, and your team will appreciate that you show your trust in them.
• Reflect the authority level of your plan in the format: Sometimes people create full plans and schedules without doing the work behind them. You've probably been in a situation where you're presented with a plan that is telling you that you need to complete all design or coding in 13.5 days, without ever having been asked how long it will take you. Make sure that your plan format reflects the best information you have at the moment, and no more. If that means only sharing a flowchart or list of milestones with key members, rather than a full schedule or Gantt chart, then do so.

Project Plan

Your project plan can (and probably should) take different forms depending on where you are in the project. Initially a simple text document describing the main deliverables, big dependencies, high-level timeline, and the key resources required for the project might suffice. Later on, though, you may decide that you need a proper schedule, probably in the form of a Gantt chart, which shows key deliverables (listed as rows) represented as bars across a timeline (typically with weeks in columns), as shown in Figures 2 and 3:

A simple Gantt chart (click to view image)

Figure 2. A simple Gantt chart, implemented in Microsoft Excel

A more detailed Gantt chart (click to view image)

Initiation Document







The most important tool for the initiation phase is very simple: it's a project initiation document that briefly summarizes why the project is happening. This document complements (but is quite separate from) the contract that you would normally sign with your client. (If your project is internal, this document complements the steps that occur within your organization before the project commences.) An initiation document helps to ensure that everyone is aligned on the purpose of the project from the start, and is much shorter than a typical project contract.





The project initiation document needs to summarize:




• the objective for the project (what you are trying to achieve)
• the key deliverables (how you are going to achieve the objective)
• the overall rationale for the project (why you are doing it at all)





Other things that should be included in the initiation document are key assumptions and constraints, as well as success criteria. This document should be a maximum of two pages in length.

Essential Tools for Getting it Right

I've asserted that being successful at PM isn't hard, and now I'm going to introduce you to a set of essential tools for the arsenal of every web project manager. Each tool has its own strengths and weaknesses, from those that are best for communication, for gaining a better understanding of what needs to be achieved, for collaborating with your team, to those that help you keep in control of your project. It's important to understand a given tool's strengths in order to ensure that you are using it appropriately.

So what's So Hard about That?

When you look at the project lifecycle this way, it all seems like common sense. So why do so many projects suffer from delays, overrun budgets, or fail to deliver the desired features and quality? The reality is that paying attention to the different phases of a project isn't hard and doesn't even require much time. Unfortunately, however, there are two perceptions that mean people seldom give PM the attention it needs.

Closure

Web projects don't end when the site goes live. If you've ever tried to just send a site live and then held out your hand for the check, you'll have experienced what I term the "undead stakeholder" phenomenon: people who had a stake in the project returning again and again with more requests or improvements or even just support queries. The reality is that your project isn't finished until the key stakeholders agree that it's finished, which is another reason why defining the success of the project in the initiation phase is so important.

Also of great importance to the planning stage is identifying who is going to be involved with the project, both on your side (who's going to be in your team?) and on the client's side (who will you be dealing with and receiving input from?) The term stakeholder refers to anyone who has some interest in your project; this may include the marketing people who want to use the web site you're developing as a marketing tool, the admins who will be asked to add new content, and the salespeople who may want to make sure the web site doesn't say too much and that they still have plenty of negotiation room.

It's important when identifying stakeholders to remember that hierarchy doesn't define importance where your project is concerned -- if the admin team find it too hard to update, their lack of support can be just as damaging as when the CEO doesn't like the color scheme.

Planning is very important, but often not for the reasons that people assume. There are a few reasons to plan, including:




• forming a better understanding of what needs to be achieved
• identifying dependencies (such as the design needing to be completed before it can be coded)
• communicating with the client
• collaborating with your team members, so that everyone understands the big picture and the implications if delays are experienced

The Generic Project Lifecycle

The generic project lifecycle is fairly simple -- first you begin the project (Initiation), then you go on to actually do the project (Planning, Executing, and Controlling, which form a loop, since expecting things to go right first time is rather unrealistic) and finally you finish by making everyone happy and, with any luck, receiving payment (Closure). This process is illustrated in Figure 1.

The project lifecycle (click to view image)

Figure 1. The project lifecycle (see larger image in new window)

Since typically most time and effort is spent in the Executing (completing tasks) and Controlling (keeping everything on track) phases, many people think these are the most important. It is true that these should be where you spend most of your time -- after all, nothing would be completed if you didn't! -- but they are not the most important.

The most important project phases are Initiation, Planning, and Closure.

A less abstract version of this definition is that PM is what you need to make a project happen on time, within budget, with required scope, and quality.

My personal definition is that PM is the simplest way to look like a superhero without requiring the involvement of any radioactive spiders or questionable parentage.

2. Develop and Practice Launch Procedures

The Launch Team should identify all steps and players in launching the new site. Document each step and who is responsible for executing it. Identify any problems that might occur at each step and how you can prevent them or deal with them if they do occur.

Once complete, the entire team should review the launch plan and hash through any questions, comments or edits they may have. Practice the launch plan a few times to test the procedures and ensure the launch team actually knows how to do it all.

Finally, you should document how to put the old site back into production if all else fails. Practice this as well. Hopefully you won’t need to do this but, if you do, you’ll be very happy to have planned for it.

1. Form a Launch Team

Create a team with key internal and vendor staff to plan and execute the launch. This team should draw from your web and IT staff, marketing and/or communications, web hosting company, and web developer and/or content management system vendor. Basically, anyone who either had a direct role in developing the new site or is a major stakeholder should be represented.

The goal for this team is to execute the smoothest possible launch of the new site. The team will plan and manage the overall launch. Including your outside vendors is critical since they are the deepest subject experts on launching the technology you are going to use.

The team should be formed near the beginning of the overall web site development project. Launch considerations should be discussed periodically throughout the project so that it is not treated as an afterthought. This will greatly aid the ease and success of the site launch.

For larger, high-traffic lists, you might want a hosted service. I recommend
>
Mail-List.com
>
-- it's dependable and reasonably priced. (Most hosted list services are priced sky-high for marketers.)
>

Forums:
>
There are lots and lots of forum tools here.
>
ThinkOfIt
>
published a good catalogue and links to reviews. Several of my geek mentors recommend
>
XMBforum
>
,
>
Vbulletin
>
,
>
PHPnuke
>
. I highly recommend using forum or list tools that allow users options for feeds.
>

Examples:
> 
TrailCentral
>
is an XMB forum. Also, the Fredericksburg, Va. Free-Lance Star has an excellent forum:
>
FredTalk
>
.
>

One to watch:
>
Right now, Slate.com is reworking its political di
>scussion forum, The Fray, to make it more usable, versatile, and easier to highlight the best contributions.

E-MAIL LISTS & FORUMS

Bare basics: If nothing else, you can use Google Groups or Yahoo Groups to run public or private e-mail discussion lists. Personally I prefer Google Groups because it gives you the feed option.

THE TOOLS




LinkedIn Answers: Available to any LinkedIn user. Here’s the FAQ.



• Pose any business-related question except requests for contacts, either to all LinkedIn users, to your personal contact network, or to selected people within your contact network. (Personally, I find I tend to answer only questions that come from my network, I don’t browse the public questions, but YMMV.)
• Questions remain live (can accept responses) for seven days.
• People can choose to respond publicly or privately to you.
• You have the option to display on your LinkedIn profile the questions you’ve asked or answered. This could help demonstrate your expertise and helpfulness, as well as the quality of your network.