Manuals for MSProject

Thumbing through the Project 98 manual, I found a page illustrating PERT charts, and had to laugh. How many times in my professional journey had I come across that diagram or some permutation?

I'd been called upon a few times to lead teams and plan projects, I first discovered PERT charts in some background reading on Project Management. I was fascinated with the idea for a while. Then one manager at Xerox tried to plan out a network problem with Post-It notes and string. -- That's got to be the best definiition of spaghetti every stuck to a wall!
Xerox headquarters in Dallas was an old warehouse that had been converted into offices. The people were great: intense and talented, but everywhere you turned led to some dark corner. Finally wandering out into the bright Texas sun could leave you gasping and staring for 10 minutes!

Using PERT diagrams by themselves to plan a project is just like that. They're useful as an interim step in the beginning, or to explain dependencies in a snapshot for someone, but without a timeline (-- which means spreading out across a couple of walls with miles of string for a realistic project) PERT charts lose their appeal quickly.
Ergo, the GANTT charts are what Project depends on in later versions.

I thought about taking the training to become a Project Manager a couple of times. Usually the demands of work or budget prevented me. Besides, I was already doing the work.

A couple of people chided me that it was the math that stopped me. I just shrugged. I've always been good at math, even if didn't appeal to me. Every once in a while, some article in Scientific American would light up my interest and I'd pick up a book or two. But if working with computers is a social niche, people expect mathmaticians to be hidden in dark towers and only called by name with great care.
I've always preferred more interaction of one form or another.

That's the Advanced Watsonia manual over there on the left. At this level, the training becomes more integrated and useful.

PERT-style diagrams found a couple of interesting applications in Use Case analysis and OOP.
Given a persona (a defined role for a user of a site or program), you could tack the Use Cases from your application around them to brainstorm.

And then, when designing the software to respond to those Use Cases, PERT-style diagrams are used to illustrate how one programming object works with the others.
Sun still uses this style of illustration in their training for Java. Object, methods, and data are defined in a heirarchy that can be explained to a customer easily -- with a little explanation about the choice of method names. No one but programmers really understand the naming of methods. It's a special code.

These object diagrams are effective because the design satisfies the function. They are a snapshot of how a program responds. It's the sort of thing you try not to let your customers see too often.
Instead of object diagrams, customers understand flow charts better. If you're laying out workflow with a customer, use a flow chart:

• the style is familiar and "intuitive", after decades of association with computer programming


• most word processors have clipart that can make your sketched-out work process into a professional presentation quickly


• they provide a shared conceptual space for you to check your understanding of the workflow with your customers


• they quickly define the Critical Path for a user, but..

There are two weaknesses in flowcharts:

1. Decisions that take microseconds in the human mind can look pretty hairy and complicated.


2. Flowcharts to illustrate workflow don't illustrate time frames very well.

You don't want to get lost in the minutae with your clients. That's what they pay you for. As quickly as possible, get back to them with a professional presentation and ask them for feedback. -- They'll let you know when things aren't right!

From a flowchart, you can kickstart the communication with a client and leave all the doors open. Many times, they'll come back to you with details because the diagrams are fun to work with.
Once you have the Critical Paths defined, whether we're talking about designing training, websites, programs, or projects, you're about halfway home.

None of the old sayings is always true.
"Take care of the big things and the little things will take care of themselves." makes you wonder who wrote: "The Devil's in the details."
-- And the guy who looks to this one: "Take care of the little things, the big things will take care of themselves.", is under treatment for OCD! (I love the Monk detective series. Does it show?)
And sooner or later, we all fall back on: "Don't sweat the small stuff. -- Hint: It's all small stuff!"

UML is still better left as a language for the techies.