The second day of AngleBrackets was another productive day for me. It also (accidentally, I swear!) turned out to have a lot of Juval Lowy and his project design courses, so the more technically-inclined people out there may want to skip to Day 3. The rest of you, anyone who is even the slightest bit interested in improving our projects, read on and for God's sake go download the slides.

Software Project Design

This was the first of two sessions by Mr Lowy that I attended today, and it started with a simple premise: as much as you design the software itself, you should also design the project itself.

The presentation revolved around this concept of project design. Juval explained it like this:

Project design is to project management what architecture is to programming

Essentially, project design is laying out the entire process of how the project is going to proceed, from front to back and start to finish. It includes decision making, but is also beyond just that. The end result of project design is that it produces a project plan, a defined process by which the project will be completed on time, with acceptable risk, and within budget. Juval claims that while using this process his projects have maintained a 100% project success rate. That sounds pretty incredible to me, but who am I to judge?

As for an overview: project design steers all managers (even bad managers) into making good decisions by simply presenting only good decisions backed up by data and models. The objective is to keep the project on time, all the time, by predicting what possible paths the project can take and what dependencies each position in the path relies on in order to be completed. The entire process is derived from engineering: get the data, use it in a model, and use the model to define the design.

The concept he stressed the most was the idea of the critical path. It goes like this: in any project, there are multiple paths from A to Z that can get a project completed. A might lead to B and C, B might lead to D, D and C might lead to E, and so on. The critical path is the longest route from start to finish; it becomes the minimum amount of work that must be completed in order to complete the project. Resources (e.g. programmers like you and me) should ideally be working on the critical path features before working on anything else.

If this isn't making sense, download the slides from the presentation; they include some wonderful graphs and charts.

Other concepts he covered include float, estimations, earned value planning, and other concepts that to a newbie like me were eye-opening and kinda scary. Still, they were exciting, and now I'm looking forward to integrating them into my day job.

Advanced Techniques in Project Design

Juval time again! In this class, he took the concepts from the previous session (as well as some from yesterday's session) and started showing how his group iDesign has implemented them in a real, objective, meaningful manner.

Techniques include using an arrow diagram (which represents activities as transitions between goals rather than the goals themselves) instead of the more-common node diagram, and something that's probably the most interesting thing I saw today: a time-cost diagram.

Yes, I am excited by graphs. Fight me.

Here's how you read this: the longer a project takes, the more it costs (obviously). However, if you want to get a project done really fast, it also costs a lot of money because it requires a lot of people. Further, you don't want either too little quality (not enough functionality) or too much quality (which descends into gold-plating); you want a balance. Finding that balance is part of the project design process, and with this method you find it and prove that it is where we think it is.

All of this lead to what Juval called "the most important advice you will ever receive in your career."

Treat the company's money like it is your own.

After all, if the company penalized the project manager personally for every time the project ran over budget or over schedule, do you think he'd invest the time upfront to find out exactly how much the project was going to cost? This is something I'll have to keep in mind.