Based on yesterday’s comments, it’s past time for me to define what I mean when I talk about product management, product lifecycle management, lifecycle choices, and project management. Here goes: Product management: The activities that plan the product’s evolution from birth to obsolescence. In a product company, product managers perform these roles. In an IT […]
A client was optimizing for what they thought was the bottleneck in their software development: the testers. In the assessment, I gathered some quantitative data about how long the testers took to test and how long it took for the other groups to perform their work. (They used a phased lifecycle.) The testers were
Want to make sure you complete your project as early as possible? Define release criteria. Release criteria are the few critically important objective criteria that define what “done” means for your project. Sometimes, it’s a combination of date, defects, and feature completion. Sometimes it’s just the date. The formula for defining release criteria is: Define
Joel’s discussion of project managers (MS calls them program managers) and developers got me to thinking about the differences between project managers and developers. The difference between project managers and developers is where they deal with complexity and decision-making. PMs deal with complexity and decision-making between people. Developers deal with complexity and decision-making in
We were on vacation last week in Breckenridge, CO. I enjoyed it, although it did take me a few days to acclimate to the 9600 feet altitude. Returning on I-70 East, we saw some great road signs: Truckers don’t be fooled – 4 miles steep grade Truckers you are not done yet – 1.
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
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.
I’ve been thinking a lot about the comments people made on the Best Practices Don’t Predict Project Success post. (Thank you for your comments.) Here’s my experience. Great people, people with sufficient functional skills and domain expertise can trump process, good or bad. Good process, process appropriate for the context, will help those people. But great people
I received an intriguing email this week asking this question: ” [..]if we were to put a quantitative value against each best practice, summed them up, and compared the total against a possible maximum could we have a predictor of project success?” No is the short answer. Here’s why: People need to first select which