Madame Blossom's Book of Poems

Monday, May 22, 2006

Jerry Maguire on IT Projects

Sometimes I feel like Jerry Maguire when I go emailing my moral thoughts or sharing best practices with my colleagues and bosses. I used to do that once in a while, but now I've mellowed down A LOT, in fact I've totally stopped. I've decided to keep to myself, doing the work allocated to me, and not get involved in other discussions that I'm not put in charge of.

Answer only when being asked. Do only when being tasked.

I don't want to end up like Jerry Maguire. I'm not ready to lose my job and start my own business - although I would very much like to. Start a business, that is.

There is also another reason why I stopped. I realise it doesn't make a difference. If anyone really wants to improve, they would be going out of their way to find out how to and do it. They don't need to be pushed. But if it's just not in their heart to do so, you can send them to courses and seminars costing the company thousands of dollars and it still doesn't make a difference. It's the same whether you send them or you don't. Hmm this sounds familiar... yes.... teringat pulak satu ayat Quran..

As for the disbelievers, it is the same to them whether thou warn them or do not warn them; they will not believe.
Al Baqarah 2:6

Subhanallah, how it fits.

Well, back to the topic.. the reason why I thought of this matter, is.. I came across the following that I sent to my colleagues and our vendor, when we were starting a project .. (yup I'm still spring cleaning emails..). These are really good and real points to note on, for IT projects, and non IT projects. And in our project, we did all the 'don'ts' and ignored the 'dos'.

=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=

Dear ppl,

I have recommended this book to some of you. The book is called "The Mythical Man-Month" by Frederick P Brooks.

I know at this time, nobody has the time to read books, or even have time to have a proper meal or sleep!! :( I've managed to find this compilation of 10 good messages you get out of the book which is so relevant to ANY IT projects.

It is more important to us now than ever. Some of the points may need you to read the book, in order to understand further - but you may also ask me personally - if I can still remember the details of that section.

But anyhow, let's keep up to what's expected of us and the schedules! Me included...

From Frederick P Brooks in "The Mythical Man-Month"

1. More software projects have gone awry for lack of calendar time than for all other causes combined.

2. Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date.

3. Brook's Law: Adding manpower to a late software project makes it even later.

4. .. He found that his programming teams were missing schedules by about one-half each job was taking approximately twice as long as estimated. The estimating error could be entirely accounted for by the fact that his teams were only realizing about 50 percent of the working week as actual programming and debugging time. Machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, personal time, etc. accounted for the rest.

5. The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to the customers.

6. When one hears of disastrous schedule slippage in a project, he images that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes; and the schedule has slipped imperceptibly but inexorably. Indeed, major calamities are easier to handle; one responds with major force, radical reorganization, the invention of new approaches. The whole team rises to the occasion.

7. It is more important that milestones be sharp-edged and unambiguous than that they be easily verifiable by the boss. Rarely will a man lie about milestone progress, if the milestone is so sharp that he can't deceive himself. But if the milestone is fuzzy, the boss often understands a different report from that which the man gives. To supplement Sophocles, no one enjoys bearing bad news, either, so it gets softened without any real intent to deceive.

8. Sharper milestones are in fact a service to the team, and one they can properly expect from a manager. The fuzzy milestone is the harder burden to live with. It is in fact a millstone that grinds down morale, for it deceives one about lost time until it is irremediable. And chronic schedule slippage is a morale-killer.

9. The project manager's chief daily task is communication, not decision making; the documents communicate the plans and decisions to the whole team.

10. How does a project get to be a year late? One day at a time.

Enjoy the week ahead! =)

No comments: