From the Trenches of Business Management Consulting
Monday, March 13, 2006
TocSim available at RubyForge
I have just set up a TocSim home page at http://tocsim.rubyforge.org/, and made TocSim available on RubyForge. There is no gem package or tarball available yet, so anyone interested will have to download directly from the repository.
Fascinating. I've been following your Variance Trap series with great interest. The value of small batches cannot be overstated. Does your research show whether other planning techniques are effective in increasing predictability? It seems that one way to manage the variance trap would be to plan slack, another technique that almost no IT project managers use.
Planning slack is definitely one way to do it. There are methods that are a great help in planning just the right amount. The series will get there, eventually.
One problem with planning slack is that software development projects are prone to blockages outside normal parameters. For example, a friend of mine works in a project where his employer has not provided computers for all of the developers. Some of the machines they do have are so old and decrepit that the team has had to "borrow" memory chips from other computers in the work place.
I know three different companies where management deliberately slow development teams down because they work on time and materials contracts. The management wants to increase net profit. They do not realise that they are reducing the return on investment, and therefore loose money. Talk about being hoisted on their own petards.
In one web application project I worked in several years ago, the project manager decided to remove the web server, because he could not understand what it did.
In another company, management forbade running web servers on company computers after hearing a talk on security issues. Bad news, since every development project the company had was a web project.
You can't predict when random acts of management will strike a killing, blow to a project. In my experience it happens fairly frequently. Therefore, I favor methods that focus on measuring what happens, and then extrapolate the future from what has happened in the past.
As a business advisor, I help people to develop business strategies and improve processes. I also lead projects.
As a professional photographer, I get to practice what I teach as a business strategist. And, I get to take photographs, which I love.
All my work is based on my values. My goal is that the people I work with and I learn as much as we can from each other. The best way I know to grow and develop, is to help others grow and develop.
I am a compulsive writer. My first management book, Tempo!, was published in 2010. LESS!, a collection of essays by twelve management thought leaders, was published in 2012. I initiated the project, coordinated it, and wrote a chapter about strategy.
I blog, make videocasts, and I am active on networks like Google+ and Facebook.
All my work, as a photographer and as a business advisor is based on the same underlying principles and skills.
For example, I teach customers how to use the OODA loop in strategy and skills development. I also use the OODA loop to develop my skills as a photographer.
I coach executives in basic strategic principles like the Interaction/Isolation principle and Cheng/Ch'i. You will also see the same principles at work in my photos.
The ability to translate basic principles of strategy from one strategic game, like business development, to another strategic game, like photography, is vital. It is what enables me to understand how to be useful to my customers.
Over the years I have been a software developer, line manager, project manager, editor, analyst and writer. I live in Gothenburg, Sweden. I have a son, Tim.
2 comments:
Fascinating. I've been following your Variance Trap series with great interest. The value of small batches cannot be overstated.
Does your research show whether other planning techniques are effective in increasing predictability? It seems that one way to manage the variance trap would be to plan slack, another technique that almost no IT project managers use.
http://textiplication.com
Planning slack is definitely one way to do it. There are methods that are a great help in planning just the right amount. The series will get there, eventually.
One problem with planning slack is that software development projects are prone to blockages outside normal parameters. For example, a friend of mine works in a project where his employer has not provided computers for all of the developers. Some of the machines they do have are so old and decrepit that the team has had to "borrow" memory chips from other computers in the work place.
I know three different companies where management deliberately slow development teams down because they work on time and materials contracts. The management wants to increase net profit. They do not realise that they are reducing the return on investment, and therefore loose money. Talk about being hoisted on their own petards.
In one web application project I worked in several years ago, the project manager decided to remove the web server, because he could not understand what it did.
In another company, management forbade running web servers on company computers after hearing a talk on security issues. Bad news, since every development project the company had was a web project.
You can't predict when random acts of management will strike a killing, blow to a project. In my experience it happens fairly frequently. Therefore, I favor methods that focus on measuring what happens, and then extrapolate the future from what has happened in the past.
Post a Comment