Question

WEEK 6 ASSIGNMENT

• Using your RFP or the Desktop Lab Project from Week Five - write a detailed scope statement, and then
• Answer the following questions:
  1. What problem or opportunity does the project address?
  2. What quantifiable results are to be achieved?
  3. What needs to be done?
  4. How will success be measured?
  5. How will we know when we are finished?

Answer 1

1)Brief Project Overview

Introduce your organization and the purpose of the RFP. State not only what you want the service provider to do but also why: what is the central “pain point” your organization has? If it’s a website redesign, what about the current one isn’t working for your purposes? This is high level, so be brief. The details will come below and a birds-eye view is fine.

2)Your Organization’s Background

Describe your organization, what it does, and what you do. There’s a good chance we’ve never heard of you and may not be able to figure that out by visiting your existing web site (which may be why you need a new website). Additionally, tell us a little about your values. What makes you unique? Why does what you do matter?

3. Project Goals & Target Audience

Explain what you plan to accomplish or what outcome you have in mind. What are the three most important things that, if done well, will make the redesign a success in your eyes? Do you know of any quantitative metrics that will help, such as increased sales or more newsletter subscribers or better-qualified leads? Think in terms of what you want visitors to the site to do, not just what you want them to see.

4. Sitemap

One of the main reasons people reach out to NMC for a redesign, beyond a dated visual aesthetic, is that the content is poorly organized or hard to find. As much as the visual design impacts visitors' perception of your company is the information design, which in turn reflects how well you've thought through your major site sections and navigation schema. If you already have a good idea how you'd like to reorganize it, include that here. (If not, that's OK too! Expect it to be one of the first things you'll do during the discovery phase with your vendor.)

The sitemap will help you determine which new content you need to write and what from the existing site will be migrated. Much of it may be outdated or irrelevant, so new copy will need to be written (especially if you're introducing a new product, service, or initiative). What does make it over to the new site will have to be imported into the content management system; be sure to let the vendor know whether that's something your team plans to do or whether you expect the vendor to handle it. Giving the vendor an idea of what content is moving helps them understand the size and scope of the site.

5.Scope of Work & Deliverables

Here’s where you want to provide more detail about the project. To the extent you can, describe all the services you know that you’ll be hiring a web team for. For example, with a web redesign project, you might be paying for:

• Project management
• Content strategy
• Copywriting
• Illustration
• Information design
• Visual design
• Search engine optimization
• Front-end coding (HTML/CSS, animations)
• Back-end coding (CMS, 3rd party APIs, custom software/features)
• Custom software or app development
• Mobile device optimization
• Testing & quality assurance
• Paid search placement/advertising
• Software training

6.Timeline

You may not know how long something will take to do, but you do have a timeline you have to accomplish it within. Is there some hard deadline you need to hit, such as the launch of a new product or ad campaign? Maybe you have a big trade show coming up and need the site live by then? Be sure to mention any firm dates beyond the vendor selection process.

Be advised: web sites vary widely in their time to completion. Even very simple sites can take as much as 4 weeks; it can take time to assimilate your organization’s goals, values, and unique market proposition. In other cases for complex sites or web applications, 9-12 months is not unusual. Be up front about your timeline, and your vendors will be honest about its likelihood.

7. Technical Requirements

This is a pretty broad subject but your goal here is to describe what limitations or requirements you know in advance. A website is, at its core, a technical software product, so these are the details that may most materially impact the schedule and deliverables. Some examples of technical requirements include:

• E-commerce: Do you expect to sell products or charge credit cards? A non-profit may only want to accept simple (or recurring) donations but retail merchants require shopping carts, user accounts, inventory control, and shipping calculators. You’ll definitely need to encrypt the transmission via SSL, which incurs an additional annual fee, though depending on the solution, this may be included.
• Content Management Software: Do you require something specific, such as Drupal or Wordpress? Are you open to alternatives you may not be familiar with? (There are literally thousands of off-the-shelf CMS software options.) The vendor may also have developed an in-house solution that will meet your needs well. Large projects can require writing custom ones for you company.
• Back-end Programming Language: For custom web software development, is your system compatible only with a specific language, such as PHP, or Ruby, or Python? Do you have an existing infrastructure that the vendor needs to be fluent in?
• Legacy Browser Support: How many visitors are still on old browsers, such as Internet Explorer 8 (released March 2009)? Do they need to be supported? To make a website perform or display in a legacy browser almost always requires additional development time.
• Web Integrations: Does your organization depend on 3rd party services for things like email newsletters, marketing automation, CRM / contact management, inventory control, intranet, accounting / Quickbooks, or inventory management? If so, be sure to include the ones for which synching / integration with the website is essential and describe how you expect it to work. For example, when someone subscribes to a newsletter, the contact should be added automatically to Highrise or Salesforce. If someone purchases a product and opts in, she should be added to our Mailchimp database, etc. Sometimes this functionality will be included out of the box and sometimes the vendor will have to write something custom.
• User Accounts: Do you require membership management on your site? This would be for allowing people to access special or hidden content on your site, perhaps after submitting an email address or paying to view a whitepaper. A simpler example would be password-protected pages that anyone can see with the same password and does not require a logged in account.
• Accessibility: Do you require the website to be accessible to blind or limited-vision users? For websites whose audience skews older, larger default text and click areas will inform the design. Government & public sites often require Section 508 compliance.
• Mobile Responsive Design: Do you require a separate mobile-optimized version of the website? Most smartphones have no trouble displaying the full site and that’s enough for many users. But a layout optimized for small screens and tablets can make a big difference in the delight and satisfaction of site visitors.

8. Principal Point of Contact

Usually, most writers of the RFP are the ones who will lead the project. If not, or if there are other team members involved, specify who they are. Have you or they worked on a similar web project before? Also, do you have final authority for making decisions or is there a committee that the designs will be presented to?

9)Budget: Assets (“Parts”) & Service (“Labor”)

Yes, you really need to include your budget, even if it’s your best guess. If you need to specify a range (“We’d like to spend $x,000 but are willing to go to $y,000 for the right proposal”), that’s fine too. Websites are like cars: you can get good ones anywhere from $5,000 to $500,000. There is no price point for which you cannot find a tinkering undergraduate freelancer to put something together for you. Meanwhile, professional agencies will do professional work and the proposal will let you know the difference.

10. Web Hosting

Do you have a web host in mind already? If not, ask for options. The vendor will have clear preferences at various price points. For example, with our WordPress projects, we use and recommend WP Engine, which is tuned specifically for WordPress performance. Who handles site backups? Is there an automated process for the files and the database? Is this included, or an extra fee? Be sure to ask the vendor about its caching or content delivery networks (CDN) strategy.

What problem or opportunity does the project address?

Ans:

Scoping Choices

The primary meaning of opportunity related to a project involves the value anticipated from the project deliverable. Initial assumptions about results and costs create an expectation of value that exceeds the project's cost. The opportunity implied by this difference may be modest and realistic or wildly optimistic. The greater the overall project opportunity, in general, the more likely it will be that the benefits will be inflated, the costs underestimated, or both. Projects that are big opportunities generally represent very high overall risk.

Planning Choices

Initial bottom-up project plans rarely correspond to expected timing, cost or other objectives. To better meet the highest priorities and constraints for the project, project leaders make trade-offs and adjustments to the project plans, seeking a realistic approach to the work that conforms as much as possible to what sponsors, management, and stakeholders have requested. Opportunities for compressing schedules, conserving resources, and optimizing plans generally will result in plausible plans, but often plans with additional (and/or more probable) failure modes and risks.

Risk and Scoping Choices

One of the main reasons that project risk management is so important originates with the pursuit of project opportunities. Projects are by definition unique undertakings, so the results they are expected to deliver inevitably involve unknowns. The business case for most projects rests on the assumption that the value of the outcome will significantly exceed the project's cost. For uncomplicated, routine projects, there may be very good reasons to accept the starting assumptions regarding performance, deadlines, budgets and other project parameters. In many cases, however, initial project assumptions are based more on wishful thinking than on reliable, analytical analysis.

Aggressive and “Stretch” Goals

As in most arenas, for projects in general there is a high correlation between risk and reward. Generating significant benefits often requires taking on significant risk. The more substantial we expect the returns from a project to be, the more potential issues in achieving them we are likely to run into.

Stakeholder Risk Appetites and Thresholds

Organizations in different businesses deal with risk in different ways. Start-ups and speculative businesses such as those engaged in oil exploration have a high tolerance for risk; though the risks of failure are high, the rewards of success are seen as sufficient to make the undertaking worthwhile. More conservative organizations, such as governments or companies providing contract project services on a fee-for-service basis, will be risk averse. They tend to expect consistent success but only modest returns on each project. New project goals should represent opportunities in line with prevailing appetites and tolerance for risk.

Dealing with Risks Related to Project Goals and Expectations

As the project charter and other documents are developed, involve people who understand what is possible, and listen to them. A challenge is fine, and can be motivating, but aspiring to impossible goals or saddling a project with constraints of insufficient time, money, staff or other resources means that all possible variance will be adverse and no one associated with the project will achieve what they want. To quote Australian consultant John Edwards, “You may con a person into committing to an unreasonable deadline, but you cannot bully them into meeting it.”

Risk and Planning Choices

The second type of project opportunity management also involves choices, this time in the planning of project work. Most projects find that initial plans fall short of timing, cost or other stated objectives. In an attempt to meet aspirational goals, project leaders work to optimize the workflow by adopting alternatives that compress plans, conserve money or employ other trade-offs to better align with stakeholder requests. Even when changes are devised to address critical constraints (such as aggressive deadlines), the revisions often require undesirable trade-offs (for example, higher costs or diminished scope), increased risk and new project failure modes. Driving a plan to conform with project constraints will inevitably introduce new (self-inflicted) risks.

What quantifiable results are to be achieved?

ans:Section 1 Department's Vision, Mission, Objectives and Functions Section 2 Inter se priorities among key objectives, success indicators and targets Section 3 Trend values of the success indicators Section 4 Description and definition of success indicators and proposed measurement methodology Section 5 Specific performance requirements from other departments that are critical for delivering agreed results Section 6 Outcome / Impact of activities of department/ministry

How will success be measured?

Ans:

1. Discover your values

2. Compare yourself only to yourself

3. Measure what’s hard to measure

4. Measure results over the long-term

5. Measure outcomes, not proxies

6. Learn and iterate