With book shelves overloaded with volumes on leadership, it's not often I come across an article that seems worth adding to the existing body of knowledge. This is the exception, a report from the FT on Ronald Heifetz' course on leadership (registration needed at FT site) at Harvard’s Kennedy School of Government.
Heifetz separates leadership from authoritarian instruction, and leads a course that challenges students to tackle the chaos and confusion that may result from high-stress problem solving situations. He creates an environment in the classroom which mimics this, and pushes the students to deliver in an unstructured setting. The drop-out rate is high, but the successes rise to greater achievements.
Similar to action learning definitions (of puzzles and problems), he differentiates between two types of management problem - technical challenges (for which there is a known solution that must be recognised) and adaptive challenges (in which both the problem and the solution may not be clear). During adacptive challenges, organisations experience long periods of disequilibrium, and it is the leader's challenge to control the pace of this while ensuring that momentum continues in face of the psychological needs for stability.
Heifetz offers this teaching as a counter-balance to the notion of charismatic leadership, particularly when this connection with a single vision prevents people and organisations from tackling the real problem they face.
Thursday, 24 September 2009
Friday, 24 July 2009
Is there a way to lead large IT projects to success?
Catching up on some of my favourite blogs, I noticed on The Philosophy and Life blog that Mark is (or was) a closet IT journalist with some interesting views about the nature of current IT projects. Echoing a view from the dark side of IT, there are questions about belief (more familiar territory for Mark) - do the sellers and clients really believe in the potential success of huge IT projects?
While these stories are not limited to one sector, there does seem to be an inevitable process that runs with IT projects: the vendors send in the sales people who over-promise on capabilities, the client counters with the procurement department who drive down the price and choose the cheapest solution, and then both parties appoint specialists to manage the project, none of whom will ever (or have ever) run the operation. Strangely, although these parties are fighting a cost battle to achieve their own aims, they all have a shared goal of initiating the project.
Once the project is started, with over-optimistic estimates of delivery and under-estimated costs, the problems spiral, requiring more time and money to complete the work. And once a huge investment has been made, it is a brave manager who pulls he plug and admits the project cannot deliver. So more money is thrown at the problem. Is there a better way?
Stephen Jenner has suggested some means to control projects in his book (Realising Benefits from Government ICT Investment: a Fools Errand?), and the time for control is at the start. Projects need to be set out with a realistic view of the benefits that will be delivered and a strong view of the means for controlling the project. This requires partnership between the business owners and project owners. Instead of a battle at checkpoint meetings where the project attempts to justify its costs, a negotiation between project team seeking costs and business taking responsibility for operational delivery of value. It's not easy, but it can be achieved.
While these stories are not limited to one sector, there does seem to be an inevitable process that runs with IT projects: the vendors send in the sales people who over-promise on capabilities, the client counters with the procurement department who drive down the price and choose the cheapest solution, and then both parties appoint specialists to manage the project, none of whom will ever (or have ever) run the operation. Strangely, although these parties are fighting a cost battle to achieve their own aims, they all have a shared goal of initiating the project.
Once the project is started, with over-optimistic estimates of delivery and under-estimated costs, the problems spiral, requiring more time and money to complete the work. And once a huge investment has been made, it is a brave manager who pulls he plug and admits the project cannot deliver. So more money is thrown at the problem. Is there a better way?
Stephen Jenner has suggested some means to control projects in his book (Realising Benefits from Government ICT Investment: a Fools Errand?), and the time for control is at the start. Projects need to be set out with a realistic view of the benefits that will be delivered and a strong view of the means for controlling the project. This requires partnership between the business owners and project owners. Instead of a battle at checkpoint meetings where the project attempts to justify its costs, a negotiation between project team seeking costs and business taking responsibility for operational delivery of value. It's not easy, but it can be achieved.
Subscribe to:
Comments (Atom)