Yet more notes as I clean up my computer. My favorite is this one, and remains true.

Eighty percent of project duration is getting agreement.

Glancing over the rest of these, there are several I agree with, and some that I don't. A lot of my software methodology notions have been answered by Scrum. But not all. Not all. :-)

software projects
* estimating
* relate size to duration? How about size to price (regardless of cost/duration)? (small, med, big, huge)
* what are common elements?
* how much info is needed to make estimate?
* what info is needed to make estimate?
* estimate hours for cost and duration for schedule.

* tasks
* just a few (ten) top level deliverables/milestones
* estimate resource hours against tasks
* the more parts there are to a task, the less accurate the estimates for those parts have to be, as long as the task estimate is accurate.
* what about weekly Monday releases as tasks, with a supporting document (release features) for each task. This is easy to understand.

* confidence
* the biggest fear is that something will break
* when a client starts asking for documentation, they're losing confidence.
* however, when useful documentation is supplied as part of the project, confidence increases.
* clients like it when you seem prepared. They like it even better when you really are.

Here are some notes I made quite awhile ago. The notion is that there are some documents that should always exist for projects and applications. More importantly, which documents belong with projects (which are transitory) and applications (which we hope will be permanent)?

This makes a difference when designing source code repositories, for instance. I don't want to be moving files from project folder to project folder, when the documents should logically be part of the application.

It's obvious these notes are geared to web applications.

I may expand (even expound) on this another time.

Project Docs

Project Brief
* Mission
* Business Purpose
* Competitive Info
* Top-Level Outcomes
* Executive Site Description
* Risks
* Estimates

Task Backlog and Estimate

Site Docs

Site Brief
* Visitor Problem Solved
* Mission, goals, etc.
* Features
* Design Principles
* Architecture

Site Map
Design Elements (pages as needed)
Wireframes/Layouts
Schema
Issue Tracking

Yet more notes....

Web or Paper Based Documentation

(Customer Brief)
* Project Brief
* Schedule/Budget
* Issue Tracking
* User Interface (screens, site map, help/training)
* Programming interface (includes architecture overview, class interfaces, basic usage, etc.)
* Schema
* Supporting documents (mostly discovery)
* Environment Info (things like site URL, database locations, user/pass)

Document rule of thumb: 90% of documents are for discovery and have no client value after the project is complete.

What information is needed by someone new to a customer/project? These are the "keeper" documents.

Some documents exist "above" the project. For instance, a site often exists through multiple projects (revisions), so there would probably be a discovery site map for the project, but there should be a current site map at the customer level.
* UI
* API
* Schema

Seven Factors to Consider When Considering Windows 7

I mean really...did someone think this was clever? Or was the editor recently employed at the Dept. of Redundant Redundancies Dept.?

Now if they'd made it a palindrome, well then....

(The headline was at eWeek.)