Thomsett project management
Friday, November 21st, 2003 at 06:08pm
Today was my final day going through the three day Thomsett Project Management: Essential Techniques workshop at work. I’m still digesting it – as a tech I’m not going to be applying Thomsett on a wide scale – but I did have the following thoughts:
- Almost all of the team has done the course so why don’t we appear to be using any of it?
- It brings up some questions reagarding the structure of our team. The client relations team is really anything that isn’t code, ie helpdesk, interfaces, testing, marketing, project management, etc. Doesn’t really fit with Thomsett’s seperation of management (left bubble) and tech issues (right bubble).
- During the course I recalled that Mythical Man Month, Pragmatic Programmer and Peopleware all talk about some of the Thomsett concepts.
- Mostly it just makes common sense. So why don’t we do it?
Earlier this week I finished reading XP Refactored and one of the final comments was about how Kent Beck said that Extreme Programming is about turning all the dials, on various development practices, to 10. The comment in question (I can’t seem to find it now) said something about how anyone who has a sound system at home knows what happens when you turn everything up to full…
The relevant point I am now getting around to making is regarding the Thomsett success sliders; aspects of the project (client satisfaction, objectives, budget, on time, add value, quality, team satisfaction) are assigned a value that indicates how flexible they are. ie if the slider is fully on for time then it must meet whatever deadline, but it the slider for budget is half off then there is a fair amount of flexibility there. The important thing is that no two sliders can be on the same value (regular spacing from off to on) because you can’t have everything fully on. This concept replaces the old theory of you can have any two of quality, time or budget.
The point I’m still trying to make is that XP says everthing should be on. As other people’s experience is telling us, that will not just work…
Tagged with: project management, training
I understand your concerns.
It is patently obvious to anybody who has been around projects for more than a minute that projects always experience some change during the delivery phase. This means that there has to be some flexibility in either TIME, BUDGET, QUALITY or OBJECTIVES, or a combination of them, to accommodate those changes.
Using the Thomsett Sliders, a simple way to force management to address the requirement for flexibility is to commence the negotiation with 0 to 10 (whole numbers only) across the top of the sliders and enforce the rule that there can only be one slider on one whole number. This forces management to have a very productive discussion regarding the areas of most flexibility.
Of course, it is their (management’s) project so in the end they can have as many sliders on 10 as they like so long as they acknowledge that the more sliders they crowd near to 10 the higher the risk that the project will not meet all their expectations (project risk). Management should also be mindful of the possible introduction of business risk as a result of a lot of high sliders.
Charlie - October 25th, 2007 at 12:36 pm
Reading back through my post I believe the actual point I was trying to make is the comparison of Thomsett with the project management that is part of extreme programming specifies.
What I left unsaid was that, at the time, the senior members of our team were advocating extreme programming even though they had little experience in it. Those team members have either moved on or have learnt that extreme programming is not the silver bullet.
To this day I still believe that an established process (ours does draw a lot from Thomsett) will work for the majority of projects, while extreme programming (or even shortcutting the established process) will fail for the majority of projects. The Tortoise and the Hare comes to mind.
Stephen - October 27th, 2007 at 10:16 am