Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Monday, November 26, 2018


The Most Reason I Like Making GANTT Charts in Project Management

Okay, so I am at a bit of an impasse. Problem is, I see value in the Agile approach but I also see the need for something tangible to pass around the conference table. Something like a GANTT chart. I hate GANTT charts. They are one of those things that are too easy to make in a meaningless way that satisfies 90 percent of your stakeholders, but to satisfy the other 10 percent, you have to do stuff I don't think can be done (like, tell the future… and if I could I would not be writing this blog… I would be living off of lottery money and dictating the blog entry to someone).

example of gantt charts in project management

I am not talking about GANTT charts that show blocks of development or releases or sprints. I am talking about the ones that show development tasks and dependencies and draw a nice line from the beginning to the end. David Christiansen says:

Gantt charts look cool. The ones I can make using MS-Project show task names, durations, assigned resources, and milestones. All in color…in whatever fonts and fill patterns I want to use. In my experience, few things about a project proposal impress people so completely as a really nice-looking Gantt chart. Sad, but true.

ASSUMING you have adopted some flavor of Agile, you could, of course, produce these charts with a lot of wiggle room by organizing them in blocks that are understood to be malleable. However, this is not what a GANTT chart is supposed to be. At least, not classically. I am all for breaking new ground, but the 10 percent I mentioned before will be of two types:
  1. Where is the detail?
  2. Why are you making GANTT charts?
In case (1), they will also want to know “how much and when”. In case (2), they will want to know how much and when but understand you are not building a shed with supplies from Home Depot.
You will have to read what Ambler says about GANTT charts on this cached page, but to save you the trouble, he came to find they are regarded as the least valuable project asset.
I am a fan of educating Clients. Agile works, although for me it can be a bit cowboyish without a good leader on the team. Accordingly, I try to be that leader and explain THE PROCESS without sounding condescending, preachy, or singing. I tend to break into song when discussing THE PROCESS. It is majestic, after all.
Recently, I learned a nice lesson, again (and this time it will stick, truly). Education is great, but among the people, you are educating needs to be the person who sits at the conference table waiting to flip out when what may be perceived as ambiguities cost money. It is not even education, now that I think about it. It is more explanation. So, THE EXPLANATION needs to reach the right ears and mind. THE EXPLANATION makes sense. THE EXPLANATION is no good if it is on some random PM’s notebook and the CFO says, “I need to know when this project is going live and how much it is going to cost by end of the day! Why don’t you know this? And don't give me that EXPLANATION!”

So again, this stuff all starts with people, not technology, and not THE PROCESS. It might not always be easy to do, because the people at the conference table are often busy, but you really need to reach them, even if indirectly.

GANTT charts are also BRUF and detailed specifications for System features that are a glimmer in someone’s eye. Now, maybe BRUF is bunk, but RUP, or better, what has been termed GRIT, has value. Even if you are going into a cave and know you don't know which way it will twist or turn, you bring a flashlight and good boots (I guess… I don't know much about spelunking).
The idea of GRIT is that an integral part of delivering great software is delivering a great requirements model. Rather than trying to completely document the requirements in one big effort early on, the GRIT approach looks at modeling as an iterative process that runs in parallel, but slightly ahead of, the agile development iterations. Early in the project the requirements are typically not well understood at any level of detail but the business objectives should be clear. As the project proceeds through the initial iterations the high-level requirements should tie directly to achieving the business objectives. Each subsequent iteration should add to the model, adding detail and precision to the requirements, ‘just in time’ for development. The end result, along with great working software, is a great requirements model.

0 nhận xét:

Post a Comment