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)
In this issue of Better Software, I have the featured article, No More Second Class Testers! and Frank Patrick has a great article, “Promises and Prescriptions, How the Theory of Constraints can help cure common project ailments.” I can’t give you a URL to Frank’s article, but maybe in a month or so he’ll
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
I’ve been thinking a lot about Dale’s post about managers needing to appreciate the work. Appreciation isn’t enough, unless I’ve misunderstood Dale’s post about John Levy‘s quote. To be an effective manager, you have to understand how the work is organized, how to prioritize the work, how to assign the work, how to give people
One of the most useful decisions a project manager can make at the beginning of the project is to choose a lifecycle for the project. Here’s the way I think about lifecycles: Not every lifecycle is appropriate for every project. In fact, many lifecycles are inappropriate for many projects. If you can’t determine the requirements
Esther’s here with me this week. We’re revamping our book based on early feedback from our reviewers. We’re focusing on the core skills of managers. Of course, prioritization is in the book. In addition, we’re addressing how to speak the language of the business (to get things done through others), how to give feedback, one-on-ones,
I’m supposed to be on the other coast right now. But since I start from Boston, and this Nor’easter has taken over, I’m going nowhere fast. When I planned the trip and the client work, I’d allowed about a half-day of slack in the travel. That’s normally enough. Not this time 🙂 When you