Managing Your Website Development ?eight Easy Steps to Project Management

Managing your website development need not cause you sleepless nights providing you learn the secrets of successful project management. Perform the best practices in project management and give your project the best chance of success.

Define objectives

Objectives guide everyone on the project to your final goals. Are your objectives to sell your product online, to provide customer support, to promote investor relations? Carefully decide and clearly document your objectives.

Decide the critical success factors ?the things at the end of the project which tell you if you’ve been successful. Make them measurable so you know if you’ve achieved them. For example, the website development should result in an increase in online sales of 25% by year end.

Stakeholder analysis

A stakeholder is someone with an interest in your project’s success (or failure). Decide who they are and whether they support your project. Perform stakeholder analysis by classifying them (high or low) according to how motivated they are in helping (or blocking) your project and how influential (high or low) they are.

Highly influential and supportive people are your allies. Gain their support whenever you can. Aim to reduce the influence of people who are both highly influential and against your project as these people could act to damage your project.

During your stakeholder analysis, draw up strategies for dealing with each group of stakeholders.

Define deliverables

Deliverables are tangible things produced during the project. Talk with key stakeholders to help define deliverables. Will your website design include web page layouts and sitemap for use by the programming team? What is the content for each page? Write all this down.

Key stakeholders must review and agree the deliverables accurately reflect what they expect to be delivered.

Project planning

Define how you will arrive at your objectives. This involves planning how many people, resources and budget are required. If delivering this in house, decide what activities are required to produce each deliverable.

For example, you might decide a web designer will develop page layouts and navigation diagrams. You might decide the marketing team will supply all product details and photographs. You might decide the finance manager will set up merchant and payment gateway accounts to enable e-commerce transactions via your website. If outsourcing work, specify exactly what the sub-contractor should deliver.

Estimate the time and effort required for each activity and decide realistic schedules and budget. Ensure key stakeholders review and agree the plan and budget.

Communication planning

Hold a kick off meeting with the team and explain the plan. Ensure everyone knows exactly what the schedule is, and what is expected of them.

For example, the web designer needs to know that he is to produce page layouts and navigation diagrams based upon the marketing manager’s requirements. He needs to know his expected start and end times.

Share your project communication plan with the team. This should include details of report templates, frequency of reporting and meetings, and details of how conflicts between teams and their members will be resolved.

Project tracking

Constant monitoring of variations between actual and planned cost, schedule and scope is required. Report variations to key stakeholders and take corrective actions if variations occur. To get a project back on track you will need to juggle cost, scope and schedule.

Suppose your programmer hits technical problems which threaten to delay the project. You might recover time by re-organising or shortening remaining tasks. If that’s not possible, you might consider increasing the budget to employ an additional programmer, or consider reducing the scope in other areas.

Be aware that any adjustments you make to the plan might affect the quality of deliverables. If you need to increase the budget, seek approval from the project sponsor.

Change management

Once started, all projects change. Decide a simple change strategy with key stakeholders. This could be a committee which decides to accept or reject changes which comprises of you and one or more key stakeholders.

Assess the impact of each change on scope, cost and schedule. Decide to accept or reject the change. Be aware that the more changes you accept the less chance you have of completing the project on time and within budget unless you reduce scope in other areas.

Suppose the marketing manager wants to add a popup window to display full size photographs of products. Assess the impact of this change. You might need to remove some remaining tasks to include this change and stay within budget. Or, it might be impossible to include the change without increasing the budget or schedule.

Don’t blindly accept changes without assessing the impact or your project will overrun.

Risk management

Risks are events which can adversely affect the success of the project. Identify risks to a project early. Decide if each risk is likely or unlikely to occur. Decide if its impact on the project is high or low.

Risks that are likely to occur and have high impact are the severest risks. High impact but unlikely risks, or low impact but likely risks pose a medium threat. Unlikely and low impact risks pose the least threat.

Create a mitigation plan of the actions necessary to reduce the impact if the risk occurs. Start with the severest risks first, then deal with the medium risks. Regularly review risks. Add new ones if they occur.

Suppose the marketing manager cannot decide what he wants from the website. Without knowing what the marketing manager wants, the team cannot deliver a website to meet his expectations. You assess this risk as highly likely to occur and having high impact. Your mitigation plan might be that the web designer develops page layouts to be reviewed by the manager early in the project.

Summary

Performing best practices in project management will give your website development project the best chance of success.

 

Simon Buehring is a project manager, consultant and trainer. He works for KnowledgeTrain which offers training in project management and PRINCE2 trainingin the UK and overseas. Simon has extensive experience within the IT industry in the UK and Asia. He can be contacted via the KnowledgeTrain PRINCE2 project management training website.

The History and Development of Microsoft Vista

For a little over five years, expectant consumers looked with great anticipation to the commercial release of Windows Vista. Since its commercial release on January 30, 2007, people are wondering, “What took Vista so long?” Perhaps a brief tour of its history will shed some light on the question.

Longhorn

Crucial to any account of the history of Vista are Whistler, Longhorn and Blackcomb which are actually real names of places in British Columbia. Both Whistler and Blackcomb are ski resorts while Longhorn is the little bar in between the two ski sites. In Microsoft, the names became code names. Whistler was actually Windows XP, Longhorn was Windows Vista and Blackcomb is yet an unknown higher operating system version. If you get the analogy between the actual places and the operating systems, you would easily understand that Windows Vista is intended to be an interim system.

The Beginning

Even before Windows XP was released, Microsoft made it known that since May of 2001, they were working on the development of a new operating system. The general excitement became apparent and since the second half of the year 2002, build leaks, both fake and real, crept into the internet. As early as June 2002, there was already some talk that Vista would have improved security features and a more modern look. By October 20, 2002 however, the first Longhorn build leak showed that it seemed much like Windows XP. There was a succeeding leak on February 28, 2003 though that showed that Windows Explorer would sport a new Plex theme.

By the last few months of 2003, the development of Windows Vista suffered a setback when Microsoft realized that they were not making good progress. It seemed as if there was no apparent focus on what the final product should be. The path of Longhorn then had to be properly mapped with the goal of making Vista better.

It somehow became apparent in the middle of 2003 that Longhorn would never make it for an early release. The release was then pushed to the early part of 2005. Some saw this as a sign of Microsoft’s commitment to the development of the new system.

By April 30, 2004, a hint of Aero transitions were seen for the first time. The jade theme and additional sidebar tiles were seen on another build leak on May 4, 2004.

The Final Stretch

The style of Aero finally came into focus in an April 1, 2005 build. Two months after, the name Windows Vista was unveiled. For many, the system name brought the hope of achieving greater ease and clarity.

On July 27, 2005, Windows Vista Beta 1 was released. Beta testers had their first taste of a new user interface, virtual folders, parental controls and networking stacks. Windows Vista Beta 2 followed on May 23, 2006 which was made downloadable for users in the following month. On November 8, 2006, the final build had been made. The final product was finally made available on the market on January 30, 2007.