Sunday, November 14, 2010
A Developers Perspective on IT Project Management
Have you read the parable of the idiot flowers? Today, let's explore the relationship between IT developers and others IT roles...
Once upon a time, in a land far, far away there was a developer and a business customer where IT and the business were aligned. The developer and the business customer worked hand in hand to develop high quality working software. Iterations were frequent, quality was high and process was minimal.
One day, the developer was asked a strange question in which he didn't know how to answer. He knew he need some help from his peers but they didn't know the answer. The one day, out of the blue a person appeared wearing a cape. He was known as the Architect. The developer asked the architect for insight and the architect provided the answers with ease. The developer became delighted and wanted to work with him going forward.
The developer and architect were happy, they did lunch together but yet something still was missing. The developer wanted to spend more time writing higher quality code and figured it would be good if he could get some assistance in writing documentation, taking meeting minutes and being able to concentrate on things he enjoyed. Then out of the sky appeared a business analyst who came to his rescue and quality improved.
The developer, the architect and the business analyst all became happy friends and had a synergistic relationship. The three of them combined were able to do the work of five developers working solely and the business customer became even more delighted. The team wanted to improve and realized that they were close to perfection, but still wanted to get better.
The developer asked himself, is it a good practice for me to quality assurance my own code and concluded that testing before handing over to the business customer could further increase the delight of his business customer and the quality assurance engineer was born.
IT was at its peak, business aligned, delivering high quality working software in a cost effective manner. The team was whole and satisfied. Then one day, a strange person appeared on the scene carrying a checklist and a clipboard. Then team inquired as to who on the team requested this individual but no one did.
The project manager immediately started to implement requirements on the team that had absolutely nothing to do with delivery of software and instead changed the team's focus to process. Going forward, every time the developer talked with the architect, they were required to document their conversation. Over time, the team stopped talking to each other.
The project manager then introduced a methodology that was supposed to aid the developer in estimating how long something would take but over time, the estimation process started to take longer than the process of writing code and morale took a turn for the worse.
The project manager also required weekly meetings which caused everyone to wait till the meeting to discuss issues instead of talking with the frequency observed in the past. Not to be outdone, the project manager declared themselves emperor of all things IT and made the business customer talk to no one else.
Anyone care to guess why IT suffers from cost overruns, lack of business alignment or stifled innovation?
| | View blog reactionsOnce upon a time, in a land far, far away there was a developer and a business customer where IT and the business were aligned. The developer and the business customer worked hand in hand to develop high quality working software. Iterations were frequent, quality was high and process was minimal.
One day, the developer was asked a strange question in which he didn't know how to answer. He knew he need some help from his peers but they didn't know the answer. The one day, out of the blue a person appeared wearing a cape. He was known as the Architect. The developer asked the architect for insight and the architect provided the answers with ease. The developer became delighted and wanted to work with him going forward.
The developer and architect were happy, they did lunch together but yet something still was missing. The developer wanted to spend more time writing higher quality code and figured it would be good if he could get some assistance in writing documentation, taking meeting minutes and being able to concentrate on things he enjoyed. Then out of the sky appeared a business analyst who came to his rescue and quality improved.
The developer, the architect and the business analyst all became happy friends and had a synergistic relationship. The three of them combined were able to do the work of five developers working solely and the business customer became even more delighted. The team wanted to improve and realized that they were close to perfection, but still wanted to get better.
The developer asked himself, is it a good practice for me to quality assurance my own code and concluded that testing before handing over to the business customer could further increase the delight of his business customer and the quality assurance engineer was born.
IT was at its peak, business aligned, delivering high quality working software in a cost effective manner. The team was whole and satisfied. Then one day, a strange person appeared on the scene carrying a checklist and a clipboard. Then team inquired as to who on the team requested this individual but no one did.
The project manager immediately started to implement requirements on the team that had absolutely nothing to do with delivery of software and instead changed the team's focus to process. Going forward, every time the developer talked with the architect, they were required to document their conversation. Over time, the team stopped talking to each other.
The project manager then introduced a methodology that was supposed to aid the developer in estimating how long something would take but over time, the estimation process started to take longer than the process of writing code and morale took a turn for the worse.
The project manager also required weekly meetings which caused everyone to wait till the meeting to discuss issues instead of talking with the frequency observed in the past. Not to be outdone, the project manager declared themselves emperor of all things IT and made the business customer talk to no one else.
Anyone care to guess why IT suffers from cost overruns, lack of business alignment or stifled innovation?
