Why is an agile evangelist writing a tutorial for Microsoft Project
This blog might seem a little bit schizophrenic: on one side I’m talking all go for agile software development. And on the other hand, I’m giving a Microsoft Project tutorial.
I know that Microsoft Project for many agile people is the devil in software. So, why do I teach it?
I started giving Microsoft Project classes in 1997. If you think Project is a horrible program now, you should have known it back then. It was more like riding a crazed horse than using computer software. You never knew what the thing would do. What happened is that I didn’t understand how I was supposed to really use the program in my work. Yes, after a lot of hands-on testing I started to understand the basic thought. But I realized that you shouldn’t teach specific features, you needed to make people understand the flow: how you could use the program during different phases of the project.
During a couple of years, I gave loads of Project classes and I also helped a lot of customers during implementation. I wrote two books for teaching Project. But there was one problem: I’m not that kind of project manager who likes keeping tabs on that Gantt chart. I prefer working and communicating with people, not using charts and diagrams but in dialogue. I stopped using the program myself. People around me couldn’t understand it. But I had no use for it in my projects then. Now things are different. I’m handling different types of projects and the resource planning works differently. And then an individual sent out a question on LinkedIn about how one got to learn to use Microsoft Project. I thought it would be really interesting if I could teach someone I knew nothing about a program which is perhaps the worst used on ordinary computers.
I think that the program can be really powerful in two ways. Used correctly for the right type of project, it can help project participants understand the boundaries of the project. Today, for example, I could use Microsoft Project to show our managers that their schedule for releases does not work with the tasks ahead of us. There is simply not enough duration.
But most of the time Microsoft Project is used wrongly. Without understanding how it works people make plans which looks accurate but are flawed just because the settings were wrong or the field was misunderstood. You could also be dealing with a Project champion, who can dupe anyone. A former boss of mine knew my skills and could order a Gantt chart which collapsed when we included a feature he didn’t wanted. Instead if him telling the CEO that the feature could not be implemented, he made Project say it.
Many of these problems can be solved by educating people about Project. Some might realize that the program does not work for them. And they might stop using it. Good! Others might realize that they were using it wrongly and change something and things work better. Also good! Even others start to understand how the program works so they can question the Gantt charts and the plans. And here lies my main motive in posting this on my agile blog. If we in the agile community understand Microsoft Project, we can question the plans.
So, even if you hate Microsoft Project but there are persons in your surrounding which are using the program, do try to understand so you can be a skeptic instead of just a critic.