Web development
Project factors
Managing Project Creep
Back End
Front End
Project Creep
Project Triangle
Agile Platform
Reasons why Projects Fail
MoSCoW priority
perché pianificare?
Usability factors
Wireframes
GOOD vs. RED FLAG CLIENT
Project factors  
Web development - project factors
ideas to for implementation


Web development - project factors
------------------------------
General Design Requirements
------------------------------
Project Factors
Kelly Goto is correct when claims that the Project Factors should be known on the beginning of the development process, at least vaguely.

• Content: from simple static to complex dynamic data base driven web pages
• Functionality: from simple marketing web pages to complex interactive application
• Stakeholders: from client participation during development to autonomous team
• Business Requirements: from unchangeable (specified in advance) to flexible / should feature creep be accepted, with expansion of a project or mission beyond its original goals? * MoSCoW priority
• Deadline: from fixed date to flexible non specified delivery date
• System Autonomy: from system tied to the legacy software to absolute independent system

The implicit design specification for the FrontEnd of this project is given in the collection of HTML pages. The final FrontEnd solution should produce valid table-less CSS layout. Final dynamic rendering layout should be exactly the same as in the files, specified by the client, i.e. same fonts, sizes, colours, paddings, etc.

---------------------------
Project Scope
---------------------------
* Define the project - in a formal estimate or proposal, be as detailed as possible. This will define the "scope" of the project, what you will deliver to the client, and for what cost/time frame. Don't be tempted to give pricing "on the spot."
* Identify Client Accountability - who has change/approval authority for the project? The last thing you want is to be making changes based on the feedback of someone who does not have the authority to actually make changes, or formally approve them.
It's a good idea to establish one main contact person at the client's organization. All changes/additions get channeled through this person to you.

* Establish a project change mechanism - For me, this is email and todo list. Any - and I mean any - alterations/corrections/additions to the site must be forwarded to me in writing by the lead contact person. "Verba volant, scripta manent"

* Indicate if you are going to include a set number of changes as part of the fee. In graphic design, it's typical to create more than one design for the client to pick from, and allow for a certain number of changes to the design, before it's a approved. In terms of the web, you want the design nailed down before you start any serious web page development.

* The first couple small requests tend to receive a verbal *advisement* from the designer/developer that the items are not within the "scope" of the project, but will be done at no charge.

* If this becomes habitual, the client is again advised the changes/corrections are out of scope, and that a new estimate will be created or a "per change" fee will be applied. Bringing this fact to light before you make the changes, will cause the client to consider the importance of the change. Sometimes the client will say forget it, other times the client will ask you to cost it out. The important thing to remember is that you are informing the client up front, not after the fact in a billing line item.

Proper communication on a project is essential. Good web sites aren't built in a day - in most cases we are talking weeks, or even months. It's important to keep the development team, and the client, up to date on the status of the project.

---------------------
Core functionality
---------------------
Start small! Iterate with small increments! As long as the core requirements remain, everything will be fine. Additional functionality can always go into "the next release," but if you don't deliver the core functionality, there won't be a next release.
A really experienced project manager might even include in his project with a little superfluous functionality that could be sacrificed if/when the crunch comes, and it will come sooner or later.
Cutting functionality may seem a drastic measure, but an experienced project manager will happily whittle away functionality as if they were peeling a potato.

Scope creep is the almost unstoppable tendency a project has to accumulate new functionality. Some scope creep is inevitable since, early on, your project will be poorly defined and will need to evolve. A large amount of scope creep however can be disastrous.