Here’s the outline we used for Managing a Project. This covers all the questions and discussions we had (and even has an anecdote at the end).
As you could tell, the point of the session was not to explore the formal aspects of project management (other than the triangle: Scope, Cost and Time), but to explore the issues that affect our ability in general to management projects. There are plenty of good materials on the actual process–although the key to most of them is to KEEP IT SIMPLE and not get caught up in the mechanics of the proces–that is one of Joel Spolsky’s points in his materials.
- How we think about projects
- How we decide which projects to work on, and in what order
- How we negotiate with each other about what the scope really is
I also wanted to emphasize the difference between a project and a process.
- We need to focus more on our process for managing projects, including how much of it we can standardize the process without standardizing the final CMS the client sees. (that is, Standardize on the Process, Customize on the Client)
- We struggle with our projects as much because of the process as with our ability to manage projects
- We disrupt ourselves because we do not have a process.
- If we want to improve, we need to pay attention to our own behavior
Examining Our own behavior
- We need to understand how we are using our time
- Not just report time, but track time and understand time
- Compare the time we actually use to the time we thought we would need
- how good were we at estimating time
- how should we be allocating our people so that we have “enough time”
- Remember Joel Spolsky’s simple chart
- Understand how much we are spending on each project so that we can decide whether we are spending time on the right projects
- Understand how we choose which projects to work on, and establish a more rational process for making those choices


To the extent that we have a standard CMS implementation project plan (and can educate our clients about that plan and process) the more we can streamline our own work.
Still, we need to learn better to control the process of settling on the “Scope” of the project if we are going to have any control over the project.
- We need a process for developing a consensus within FNC regarding the scope
- We need a process for settling on a reasonably predictable scope of work with our clients that we can all generally live with (understanding that the process of development often reveals places where the scope should be changed).
The final mantras are:
And don’t forget all of your negotiating skills, since those are the most important in establishing the scope and timing of any project.
GOOD LUCK.