« Project Management: Make it Happen
Minimise Your Project Management Documentation »

Project Management: Take the Leap

September 11, 2007 | Author: PM Hut | Filed under: Project Closure

Project Management: Take the Leap (#4 in the series Small Business Project Management: Turning Great Ideas into Reality)
By Jeri Merrell

Take the Leap is article 4 of 4 in a series on Small Business Project Management: Turning Great Ideas into Reality.

You’ve dreamed. You’ve planned and designed. You’ve rolled up your sleeves and dug in. Now it’s time to take the leap!

Tell the World

Now is the time to pull the trigger on that communication and marketing plan you came up with during the idea refinement stage. You did come up with one, right??

  • Announce your new product to the world. You can start teasing your customers fairly early and build up from there. This isn’t a marketing blog – so go to one of those for more advice on that.
  • Use this as an opportunity to advertise to new customers on other sites, try guest blogging, use targeted email, in print media, and via other channels
  • Consider radio spots, speaking in person or via webcast, attend professional conferences and use other networking opportunities
  • This is a great opportunity to extend your business branding, so ensure the look and feel of any marketing communication and press releases are professional

Actual Deployment

It’s usually a good idea to launch the product – upload it, activate new code, swing your DNS, take whatever steps are necessary to make it live – during your slowest part of the day. Often, this is the wee hours of the morning. This is a common enterprise IT and network management practice – and investing a couple of sleepless hours is well worth it! You can make sure that everything is up, running and perfect while there is no demand on your site, rather than making changes while customers can see the glitches involved.

Immediately after making your new product active, test it thoroughly. Make sure that all links work, all functionality works, all typical user scenarios run flawlessly.

It’s a good idea to have a fallback plan in the back of your head. What happens, in a worst-case scenario, if you upload your new code or product and it breaks your site? Do you have a backup? How long are you going to give yourself to try to get it working? At the decision hour, what’s your plan for restoring the old version and how long will it take?

Unparalleled Customer Service

Now that your new product is out there, released into the wild, what’s your plan for supporting it? Customers will follow you anywhere if they believe you are providing superlative service.

You might want to consider the following:

  • An email link or contact form on the product for support, with response or availability standards listed
  • An instructions and frequently asked questions page supporting your product
  • Some general triage assistance from an assistant immediately following your launch to help with handling any immediate calls and emails
  • A support forum where users can support each other with questions and issues
  • With an information product, a “call to action” – a follow on program that customers can participate in to apply the information they’ve gained from your product, via community forum or other media

Evaluate your Project

At the end of the day, when the dust has settled and you’re back in relatively normal operating mode, you should sit down and evaluate both the success of your project AND your capabilities as a project manager.

It’s not an academic exercise! The point – the first and primary goal – of this evaluation is identifying a few things you can do better next time around, and then doing ‘em.

I will share that the some of the most common problems with IT projects include:

  1. Poor communication
  2. Incomplete or undefined requirements
  3. Scope problems – the scope keeps changing and growing so the project is never done
  4. Insufficient testing
  5. Arbitrary and inadequate timelines and budgets

Ask yourself: Did you deliver what you set out to? Was the quality adequate? Are your customers pleased? Did you meet your budget and your timeline goal? Most importantly, if you were to duplicate this process for another product, what would you do differently?

Jeri Merrell, PMP, is an IT program manager for GCI, an Alaskan telecommunications company. She has worked in project management for the last ten years and her focus has been varied, exploring many facets of the industry: business process, product development, infrastructure, IP telephony, business intelligence and application development. She writes technology and business focused articles at http://www.ungeekit.com.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Tuesday, September 11th, 2007 and is filed under Project Closure. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories