Project Leadership v. Project Management

I’ve heard and read a lot about leadership and management. When it comes to projects, I can’t help but feel leadership is an overrated concept; something that is really only required by employees at low-level positions; people who need something to believe in because their jobs don’t provide fulfillment. I also think that a project team (or an organization, for that matter) that has good management, without leadership, will do better than one that has good leadership, without management.


Why? Look at how leadership is defined. Leadership is responsible for establishing direction, aligning people and motivating and inspiring. You can duplicate all of those through management – setting objectives and creating strategy and vision, coordinating resources and defining relationships and communicating expectations. Leadership however, will virtually never be able to plan and budget, organize and staff, or control and problem solve. Even if a project team or organization built on leadership is successful, it will never be as efficient (and therefore competitive or profitable) as one that is well managed.

I would like to bring up the idea that a team of professional workers, who are experts in their functional areas, don’t require leadership or motivation. These individuals need management to coordinate their efforts and provide support and resources to their activities. As a matter of fact, if this was a team of people that required "motivation, direction and guidance" (a common definition of leadership), I’m not sure that want them on my team (who wants to have to constantly “lead” people?).

From one of my textbooks: “Leaders use inspiration, charisma and inherent excitement…to motivate others.” That sounds like nothing more than a sales pitch to me. Can’t we have a team of rational people who are able to deliver results and adapt because they recognize it’s necessary, and because they have the will to succeed; not because they have a cheerleader touting the “inherent excitement” of the change or the project?

This is not to say leadership is never necessary; it has its place. In the military, or on sports teams, when bullets are flying by and mortars are falling, true leadership can bond people together and help them focus on meeting that one single objective. But when it comes to executing in a professional environment, I know who I want on my team: intelligent, consummate professionals who are driven by achievement and need management support to accomplish their tasks, not a leader.

What drives cost overruns?

I’ve recently heard some very compelling points with regards to the systemic nature of projects. Perhaps the most poignant concept is the realization that the sum of project overruns is often greater than its parts. I know that, in hindsight, it is difficult to explain how any one change, or the uncertainty in a single arena, could have led to the final outcome. Rather, it’s the impact of the cause of the overrun, multiplied through feedback mechanisms, and by the resulting negative effect on areas of the project that may not be directly linked to the initial difficulty.

The key villains that drive cost escalation are the project organization and the clients themselves. Of course, external forces such as the changes in the regulatory environment or advances in technology can have an impact. However, even though the consequences, in terms of increased costs, may be more severe from external changes, the likelihood of occurrence is usually low (although the longer the duration of the project, the more critical this area becomes), so I wouldn’t consider it a “key” villain.

Systemicity is really an embedded reality for projects. In and of itself, the systemic structure of a project doesn’t drive cost escalation – it simply magnifies it and helps to create “vicious” or “virtuous” circles. So although it’s worth discussion and is a cause of the sum being greater than the parts, it’s not really a key villain when discussing cost overruns. Neither is schedule acceleration, because it is a reaction to project trouble, not a direct cause.

The factors that cause cost overruns, and contribute to large-scale cost escalations, typically include the planning (or control) estimate, customer interference, and customer or contractor created changes to the project plan. These cause the initial difficulties, and act as a root cause for cost escalation. These stages are usually foreseeable, and are controllable, by the two key villains I mentioned above – the project organization and the customer organization.

The real causes of cost escalation during these stages are usually the customer’s failure to provide thorough information during the planning stages, or their inability to “help” the contractor execute the project. Or it may be the contractor’s failure to follow proper configuration management techniques, or ensure a “meeting of the minds” on key project specifications. Failure by both organizations to manage these types of problems throughout the project will lead to cost escalation for each arena, and give rise to the systemic and acceleration stages that will make the team look back and wonder what happened.

An Analysis of Organizational Structure

For this post, I analyzed a regional consulting firm that has been having some growing pains. This analysis allowed me to see that the structure of the organization was significantly contributing to their problems, and would have to be changed if they hoped to improve their PM processes and operational efficiency.

The graphic allows us to see that while each member of the firm's set (functional areas) is integrated, overall communication throughout the organization is lacking. The concentration of authority and customer contact across the two major hubs (lead technician and business consultant) also presents problems in terms of resource allocation - first, by potentially overextending each hub as business grows (creating bottlenecks); and second, by creating separate factions that may not operate in a unified fashion.

This structure does not facilitate collaboration among the various groups: because of the “stovepipe” reporting structure, and the independent mindset among the functional areas (i.e. marketing operates one way with consulting clients, while the helpdesk uses their own procedures with services clients). With the functional departments empowered to manage and complete isolated projects within their “stovepipe,” there are relatively few issues for small clients with specific needs (which is why this was not a serious issue in the past). However, as the client base shifts, the efforts of more than one department will be required to develop and implement comprehensive programs – efforts that cannot be effectively managed with the existing structure.

From a PM standpoint, as this shift occurs, the functional webs converging on the two main hubs limit overall cooperation throughout the organization and with other key stakeholders. With communication and decision-making authority lying outside of the project structure, because there is no true project manager, the project team and functional managers are removed from the needs analysis, and no one maintains accountability for aggregate team and project performance. When looking specifically at the project planning process and scope definition, this structure would limit the authority and decision-making capability of a project manager. It also serves to erect barriers to teamwork, and results in disparate objectives among “competing” functional areas.

This need for better internal communication, and the division of business and technical personnel, coupled with the lack of a single project manager for large projects, makes it harder to garner scope agreement and create an all-inclusive project plan internally; even before solutions are presented to clients. With no internal consensus on what the scope or plan of action will be, it is impossible to approach the customer as a unified organization with full-spectrum expertise.

Since the firm has moved towards larger and more complex projects, their lack of sophistication and failure to create scope definitions and management plans based on key stakeholder consensus has been very difficult to overcome. As we can see, their organizational structure contributes significantly to this problem.