Analyze Weick's Argument
Leadership as the Legitimization of Doubt
Think about what Weick says about leadership and doubt. Do you agree or disagree?
I fully endorse with Weick’s assertion in "Leadership as the Legitimation of Doubt”.
Doubts and Uncertainty exist in a project in various forms and to varying degrees. Foreseen unknowns can be handled with contingency and risk mitigation plans. A response mechanism would have been logically thought out for such scenarios.
The unexpected unknowns pose a bigger challenge in terms of detection and redressal. Doubts help raise factual questions and find answers in project environments. The attempt to clarify doubtful situations helps ...view middle of the document...
On a general note, I would say that an individual in a leadership role would have to undertake an interdisciplinary and probably a multi-dimensional effort to handle the unknowns of a project. There are different varieties of uncertainty and, like medicine, different remedies are applicable.
A disclaimer needs to be made at this point so that there is no misjudgment of my analysis on this subject. I am far from handling the affairs of a project in the role of a Project Manager. My experience with leadership is with handing small sized projects with 3 or 4 peers on the team. Therefore, for this discussion, I would rely on my own study and interaction with professionals in related disciplines while addressing an audience which involves persons who are trained and exposed to the various areas of project management.
Have you ever been part of a project that faced doubt?
Yes, about 2 years back, I was part of a volatile project with an ever changing landscape. I worked as a Software Test Analyst for a global asset firm on one of their pivotal financial applications developed in Oracle PeopleSoft (Enterprise Resource Planning) ERP Software. The Test team was comprised of 4 members including the Test Manager. The software application releases to production were phased out to occur after every 3 weeks. Within 3-week duration, software requirements would have to be finalized developed and tested for release to production. However, about 25 – 30% of the software requirements were always in a state of flux. Unbeknownst, they were either included in scope or rendered out of scope or moved to another release. The Test Manager always had tough time tracking the requirements. Only the Software Development team had the first hand interaction with the customers and end users. The developers would make the necessary changes to the code and deliver it to the testing team. Within the testing domain, our test plan was seriously dented because we were not sure as to which of the software components would be delivered first. It affected our pre-planned priorities and we were always at the mercy of the development team who threw the software code over the wall.
How did you or the project manager you were responsible to respond?
The Test Manager took a lead role in defining the over all QA process and in driving the quality standards of the project. However, the stake holders and project management had a totally different view of the way things are to be driven. Big politics was at play in terms of articulating and defining the work demands...