Deciding Who Does The Work
Deciding who will carry out your web strategy once it’s developed is a major step. Maybe you have in-house staff with the skills and time to do the job, but if not, perhaps you should consider outsourcing part or all of the implementation. Here are some questions to consider when facing this decision.
What about the in-house staff?
What are their skills? Are they capable of doing the work? What training
would they need and how productive would they be?
What is their interest level? Are they inspired and passionate about new
technology? Do they want to do the work?
What is the methodology?
Is there clearly a team here and do they work well together? Do they have a record of completing projects successfully? Can they come together at crunch time to produce?
What is the team’s expertise level? What have they done before?
What would the team makeup be? Do you have team bios?
What is the staff availability? Are they working on too many other projects or can those projects be re-prioritized?
What’s the long-term strategy? Is the intent to have administration and maintenance done in-house?
Is there company-wide support, particularly among management, for the in-house staff doing the work?
What is the projected return on investment?
What outside resources are available?
Are customer references favorable?
What are the specifics of the contract? For example, who would own the code?
Are there any work guarantees?
Will there be ongoing support agreements?
Identifying the project team is probably the most critical decision you’ll make in terms of implementing your web strategy. Close behind in importance are your decisions about project process or methodology. In essence, you need to decide to employ only one.
Ensuring You Have A Methodology
In an ideal world, the people selected to do the project would be accustomed to following a process and you’d be home free. But, like most business propositions, web implementations are usually not of an ideal world. You might have to convince the people doing your implementation you want them to – and they need to – follow a formal process. I’ve included a synopsis of a methodology we use at CTR called 4dM to which you may refer. It’s a well-honed and comprehensive methodology we’ve been refining for years. “4d” stands for define, design, develop and deploy. The “M” stands for management — project management.
Getting Everyone Onto The Same Sidewalk: The Define Stage
The purpose of this stage is to ensure your requirements have been defined correctly before the actual work begins. The project team must understand your objectives and special requirements, and the team’s schedule must be realistic and acceptable to you. The define stage also seeks to eliminate misunderstandings that might otherwise arise between you and the project team, and consists of:
- scope of work
- project plan
Coming Up With The Blueprint: The Design Stage
While the define stage generally states what the project team is going to do and how it’s going to do it, the design stage results in functional and technical specifications. In other words, it says, “This is exactly what we plan to do. What do you think?” The design stage consists of:
- preliminary design
- pilot or prototype
- detailed functional and technical design
Creating The Solution: The Development Stage
During the typical development phase, developers write code and configure your website and back-end systems. This is the stage during which planning and design becomes the functional product. The development stage consists of:
- programming and configuration
- testing and quality assurance
- functional code and system configuration
Delivering A Working Solution: The Deploy Stage
With the arrival of the deploy stage, the site and back end systems are essentially finished. Only training, testing and final “tweaking” remain. The deploy stage consists of:
- training and preparation
- final testing
- the system in use
- the project wrap-up
Minding The Store
Earlier, I mentioned the “M” in our 4dM process name stands for project management. We include it prominently because project management is, as it should be in any process, a defining feature of our process.
Typically, project managers handle scheduling, resources, cost, and quality concerns. They track new issues and changes in the original project specifications and deal with exceptions to the project’s scope. They also handle ongoing project documentation including system configuration details, meeting notes, reports, form and data examples, procedural guides, system and process analyses, flow charts, entity-relationship diagrams, prototype screens and reports, and so on.
Project managers issue periodic status reviews so everyone involved is aware of progress. They also document problems for quick correction. These reviews record completed tasks, tasks not completed according to schedule, key issues and decisions made during the week, and exceptional issues or events that may affect project outcomes.
I suppose it’s possible to implement a web strategy without a formal process or a project manager — but I wouldn’t give a plugged nickel for its chance of success. Defining and deploying a Web strategy could be the most important business step you’ve taken or will take in a long time. Why not give yourself every chance of success?