Chapter 5: Development Techniques


Overview

Author: Jeffrey Haas

  • Functional needs analysis

  • Software and tools

  • The production process

This chapter is a step-by-step process outline detailing how an organization's political will to create an intranet can be transformed into a functioning intranet. It will define the process for people who need a roadmap, and encourage them to conduct proper planning themselves.

Converting the intention to build a corporate intranet into a deployed site can be a challenge for even the most experienced project managers. This is because stakeholders' expectations are usually not set properly or adequately managed.

As a project evolves through planning, development, deployment, and approval stages, the number of requests for clarification of detail is always surprising. Issues that you may have thought were clear as spring water are actually murky in some people's minds or completely disparate from what you had intended and likely explained. Often, people will walk away from the same meeting with a perception of concepts and an expectation of results that you never intended them to have. And then you'll be expected to deliver on those.

Note

Everything must be documented clearly and explicitly.

The most common complaint of intranet project managers is that they need to meet impossible deadlines and fulfill unrealistic expectations with inadequate resources. If you don't want to be mouthing these words one day, it's important for you to make sure everyone is clear on what the project's deliverables are going to be; and the only way to do that is to make sure everyone sees the same picture.

The planning stage of an intranet project is its most important part. Do yourself a favor and don't forget this or rush through it. Planning correctly and thoroughly will allow you to explicitly define deliverables, schedule, and cost. More importantly, it will also allow you to set and correct expectations among all stakeholders. You want to avoid being vague anywhere as fuzzy deliverables are dangerous - they can result in you trying to extract perceptions from the subconscious of middle and upper management.

After you've defined all the necessary parameters in the planning stage, you'll be able to control the project properly during the development and deployment cycles. Then, when something (inevitably) changes inside the project's scope, you will be able to manage expectations by showing people the significance of how the changes will impact the deliverables, schedule, and cost.

Also, note that having a quick reference to the implication of project scope change will often prevent casual outside suggestions from becoming your additional deliverables. Telling someone in a serious tone that their idea will cost an extra $30,000 and two weeks extra development time (for example) will necessitate them making sure their ideas are thought-out and approved through proper channels. Also, "change request forms" can be considered if you're a particularly process-oriented individual.

During your planning stage, you will be creating a number of documents. Make sure that they are all accessible to non-technical stakeholders. This doesn't mean that these should be written at a grade-school level, but that they are comprehensible for people who are willing to learn a bit about the vocabulary. Including a glossary in an appendix can be valuable, as it is next to impossible to write a technical document that is completely devoid of jargon.

As well, network diagrams, wire frame concepts, site maps, and timelines should be included as images for people who don't like to read or who will just be scanning your documents. It might sound silly, but including pictures in documentation can make a huge difference for those who need visuals in order to understand concepts.




Practical Intranet Development
Practical Intranet Development
ISBN: 190415123X
EAN: 2147483647
Year: 2006
Pages: 124

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net