I spoke at a joint meeting of the RI PMI and ASQ last night. My presentation was “Predicting Project Completion.” I offered a simulation for people to try: predicting the time it would take and then sorting two decks of cards. We learned a lot and had fun. At the end of the meeting, one […]
At first, when Hal posted State of the Art of Project Management — Underlying Theory is Obsolete I wasn’t sure what he meant by #9: “Project portfolio management is an excuse not to manage each project. Each project team must be set-up for success.” Now in PMO: Obsolete Before It Gets Off the Ground, I
I just read Jim Coplien’s paper about teaching design called “Close the Window and Put it On the Desktop”. He references the “Rule of Least Surprise,” which is to do the “least surprising thing.” In design, it means the user shouldn’t be surprised or confused by what the program does. But what does it
I’m writing an article about defining the rhythm or cadence of your project and how to increase that, if you want to finish the project faster. I’m a little stuck—at least, if rewriting the whole thing three times is stuck, that’s where I am :-), so here’s another observation about project rhythms. If you watched
I’m developing a syllabus at the graduate level to teach high tech (if that matters) project management to people without a lot of PM experience. I’m supposed to teach MS Project as the tool project managers schedule the work. I’ve been rejecting the idea that a scheduling tool can teach a new PM how
Laurent’s post, The team building lunch prompted a bunch of (hopefully now organized) thoughts about the role of food in high tech projects. One of the things I notice when I perform assessments is whether there is some sort of cafeteria or other food-eating place. Projects that have a physical place large enough for
Rick commented on my last post that some engineers think that status checking slows them down. Mark said that engineers push back on demos and pointless measurements and then said in another comment, “progress metrics can always be free.” Here’s how and what I look for, to determine status. If I’m managing a traditionally-planned
At Boston SPIN last night, Tim Lister of “Waltzing with Bears” fame gave a talk about recognizing and managing risk. It was great. If you ever have a chance to see Tim speak in person, do so (Yes, Tom DeMarco is also an excellent speaker, but he wasn’t there last night :-). When I
In my last post, I argued that functional and non-functional requirements are unsuitable for the art of describing requirements. I prefer to discuss attributes of the system instead, and then talk about functionality. (Gause and Weinberg wrote Exploring Requirements, Quality Before Design describe how to do this.) But Laurent, in his Misfits, or there’s
I’ve been thinking more about requirements. In the most recent two assessments I’ve done, both organizations have been stuck on thinking they could define their requirements before design and implementation. IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months)