Thursday, July 18, 2019
Lessons Learned from the Three-Week Project Turn Around Essay
In the world of computers, Information Technology and Software Development people speak a different language. They might as well be talking ancient Latin and no one will care for when they use C++, VisualBasic and Java the rest of the population would sometimes feel out of this world.            The team leaders and project managers who are leading this group of people must learn a different way of solving group conflicts and a host of business problems related to the digital world. One has to remember that though this special group is in some sort of manufacturing a product, they are by no means dealing with raw materials like wood, minerals, metals, and chemicals. They use something else and that is human resources called programmers.            Charlie Poole had the opportunity to work in this world and he found out soon that he must quickly adapt to the situation. His problem with a certain software development project was not unique to the software development company he is working for. He is feeling the pressure of seemingly insurmountable problems common to this business. In fact Poole and his team is already experiencing or about to experience a number of patterns or cycles a software development group usually encounters as described by Kent Beck in his book, Extreme Programming Explained and a few examples are listed below: Schedule slips – the day for delivery comes, and you have to tell the customer that the software won’t be ready for another six months. Project canceled – after numerous slips, the project is canceled without ever going into production. Defect rate – the software is put into production, but it doesn’t solve the business problem that was originally posed. False feature rich – the software has a host of potentially interesting features, all of which were fun to program, but none of which makes the customer much money. Staff turnover – after two years, all the good programmers on the project begin to hate the program and leave.            Again, based on his journal/project report there is reason to believe that the dreaded scenarios mentioned by Beck is looming in the horizon of Poole and his team as evidenced by his writings:            In July 2001 I spent three weeks trying to turn a project around. The project had troubles:         big requirements that said nothing, schedule slippages tat had already extended it to twice   it’s original estimate, no integrated version of the app we were developing [†¦] This was           far beyond my original commitment and I was planning to leave. At the same time, the  project manager was leaving, and a new one was not available for three weeks. (Poole)            The backdrop is set and before Poole could have reached the last level as desribed by Beck – leaving the company in frustration – the â€Å"turnaround master†Mr. Poole turned to the radical tenets of Extreme Programming (â€Å"XP†) for help.            The principles of XP can be found in an article written by Pradyumn Sharma, CEO of Pragati Software and he listed it as: Continuous Integration Small Releases Onsite Customer Planning Game Metaphor Simple Design Testing Refactoring Pair Programming Collective Ownership No overtime Coding Standards            Charlie Poole asserts that he only used four of the twelve XP principles namely, 1) Continuous integration; 2) Small Releases; 3)Onsite Customer; and 4) Planning Game. This does not really mater because the success of the team can be attributed not only in the use of XP methods but in the leadership skills of Poole.            Consider the following steps he took, becoming a sort of a maverick in that company who like the others have certain traditions and a way of doing things.            In order for the project to be completed in such a short time and with the odds not in their favor, the team and the leadership must follow an ancient truth which is the development of a â€Å"vision†. Before anything this â€Å"vision†must be first in place in the hearts and the minds of the all the members of the team including of course the leadership. A vision or a mental image of what must happen after a given time must be provided by the leader. According to Russ Finney this leader is called the professional system builder and he must in turn become a system visionary which according to Finney has the unenviable role of doing the following tasks:            His or her willingness to share insight and understanding of a situation, and the necessary         steps he or she envisions to arrive at a desired outcome, tend to be dependent on tow  factors: the level of confidence he or she has in the ideas, and his or her tolerance for scrutiny and criticism [†¦] With each passing phase of the project, he or she must constantly develop and communicate his or her vision of both the system functionality  and the project approach. (1999)            Charlie Poole did not only provide vision and listened to his team mates but he also he team but he designed an ingenious way for building it and presenting it to them. Poole did not sit in one corner of th office and wrote his vision but instead proposed the use of â€Å"stories†. Again, he demonstrated his ability to be a maverick when the situation calls for it. This use of a story works wonders for the group because of the following reasons: Simplifying the abstract world of computer programming. A creative way of allowing the Customers who may not be technically proficient to join            and contribute to the painting of a mental picture of what the project ought to be. It created a source of information from which the group can draw inspiration and also a tool to on seeing a bird’s eye view of the project that will aid in the latter stages of  integration.            Poole also did more than provide a vision, he also created an environment that minimized the emergence of conflicts between teams and team members. He probably got the idea from Ohlendorf’s work when he began to meet his team every Monday for breakfast. And instead of castigating his team for infractions he was willing to listen to what they have to say. The following statements explain why Poole was successful in this area. Amy Ohlendorf in her work entitled Conflict Resolution in Project Management asserts that learning how to actively listen will do wonders for an organization experiencing difficulty and she said:            Listening allows the conflict to take its natural course by giving individuals the  opportunity to disagree, express strong opinions, and show passion for ideas. A respect  for individual difference is demonstrated and an environment of understanding is        fostered. Listening is helpful in achieving a winning resolution by enabling an employee          to identify the criteria that is considered an acceptable outcome. As a result [†¦] trust and    a relationship bond will form preparing individuals to listen also to the needs of the   manager. (2000)            The only snag to the three week saga was when the company’s management step in to override what Poole was successfully been doing since he assumed the post – providing close proximity leadership. This way he was able to know how to make the thing work and all of a sudden management began dictating unrealistic deadlines that almost keeled the ship over. Lesson learned from that fiasco: in times of crisis lead, don’t manage.                                                                      Conclusion            Based on his journal or project report, Charlie Poole did not elaborate if he went to a leadership school or if he had had previous training in a management institute. If he did not then it can be said that he demonstrated an uncanny ability to provide high-caliber leadership for a group in crisis mode where everything that is happening points to an inevitable collapse.            Almost everything went according to his wishes – at least those that he can control – which are a testament to his leadership skills and the courage to do practice methodologies and techniques never done before. In other words he dared to do something different, for the simple reason that he was tasked to complete a job and there is no way it can be done using the normal route – the normal way of doing things around here sort of thing. And he was handsomely rewarded for his no guts no glory approach with a little help from sound leadership principles that he threw in to his bag of tricks. References Ohlendorf, Amy. (2000). â€Å"Conflict Resolution in Project Management.†University of Missouri –            St. Louis, Available: http://www.umsl.edu/~sauter /analysis/488_f01_papers/Ohlendorf.htm[30 May 2006]. Finney, Russ. (1999). â€Å"Winning Project Teams†. ItmWEB Media Corporation, Available:            http://www.itmweb.com/essay003.htm [30 May 2006]. Beck, Kent. (2000). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-           Wesley. Poole, Charlie (2006, March 4) â€Å"Three Week Project Turnaround.†Cunningham & Cunnigham,          Inc. Available: http://c2.com/cgi/wiki?ThreeWeekProjectTurnaround [30 May 2006].
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.