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.
Showing posts with label Thoughts. Show all posts
Showing posts with label Thoughts. Show all posts
Thursday, March 25, 2010
Saturday, February 6, 2010
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.
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.
Thursday, July 30, 2009
The "Theory" of Project Management
Generally speaking, a theory is a set of related ideas, principles and techniques that apply to a particular subject. Theories are typically used to explain a set of observations, and can provide us with an expectation of what should happen, barring unforeseen circumstances. However, the underlying theory of project management is somewhat implicit in nature. In other words, projects don't play themselves out systematically like mathematics or logic. What works in Project A will not necessarily succeed in Project B. The transitive property of mathematics is rarely observed in projects.
For that reason, some discussion of the conceptualizations behind the theory is warranted before discussing the fundamental considerations. The benefits of using a theory, in the context of conducting a project, are that the practical actions derived from the proper implementation of the theory can help us achieve our goals. I would start by establishing three levels of goals for any project: first, there is the general goal of getting the intended deliverable completed; second, there are technical (or internal) goals, such as cost minimization and adhering to a schedule, that means the project has been done right; and third, there are customer satisfaction (or external) goals, such as quality and functional utility, that means the right project was done right. By applying project management theory, we can (hopefully) dramatically improve the likelihood of reaching the third, and ultimate, goal.
To begin, project management is about managing work. Turner (1993), claims that work can be managed by decomposing total work into activities and tasks – that’s the basic concept. As the PMBOK Guide shows, these activities and tasks are the unit of analysis in the core processes of project management, such as scope management, time management, and cost management. Morris (1994) supports this description by outlining a project management approach based on four steps: first, what needs to be done; second, who is going to do what; third, when actions are to be performed; and fourth, how much is required to be spent in total, how much has been spent so far, and how much still has to be spent. Central to this sequence is the Work Breakdown Structure (WBS), which is a key deliverable of the project planning process, and is crucial to scope management and project control.
The PMBOK Guide provides us with a second concept in project management, by laying the groundwork for planning progression. Ten core processes, including scope planning, scope definition, activity definition, resource planning, activity sequencing, estimating, and project plan development, have been identified to guide the planning process. The outputs from these processes are the project plans, which form the inputs to the execution processes. The implication here is that if you effectively complete these steps, you’ll have the necessary inputs for successful execution, which will lead to a successful project.
These two primary concepts – the project as a series of tasks and activities, and the core planning methodologies as guiding principles – can help us understand a general theory of project management, which is thus: by undertaking a series of sequential, yet interrelated, tasks to define, plan, prepare and execute a project, you will be able to effectively achieve technical success and customer acceptance.
Although this theory sounds relatively simple, we often find that organizations have trouble putting the concepts into practice. Some of the key reasons are a combination of limited resources, lack of understanding, and the perception that there are no immediate financial benefits to justify the time spent on project management (i.e. it’s a cost-center). More specifically, young organizations view formal project management as overly bureaucratic, and as a hindrance to getting business done. Yet, these organizations are the ones who can most benefit from the application of theories that improve structure and accountability – which are direct results of the two key concepts discussed above.
Additionally, the theory of project management helps organizations gain efficiencies through standardization and streamlining. An organization that understands their own business, by analyzing and consistently following the core processes, can lower costs and enhance service levels. These core processes can be documented, allowing the organization to work on ways to improve the work-flow and customer experience at each stage. This feedback loop creates a virtuous cycle: documenting the steps to produce a deliverable will lead to more consistent application of the processes, which leads to more standardization, then to continuous improvement, and then back to documenting the improved steps.
Furthermore, by increasing consistency, deviation rates will decrease and you will find improvements in predictability – lending credence to the theory suggested above that by breaking a project down into tasks and following the core planning methodologies, we can create a plausible expectation of the outcome. This application of project theory also provides more accurate measures of project progress, which enhances our ability to meet project goals.
By ignoring the fundamentals of project management theory, especially during the planning stages, we find that customer requirements are poorly defined, and the process of clarifying and changing requirements leads to disruption. This is one of the key reasons that projects fail – incomplete or inaccurate scope definition. The constant disruptions cause actual progress to drift from the plan, which becomes too burdensome to regularly update (adding to the perception that project management is overly bureaucratic).
Without an updated plan to work from, informal management becomes prevalent. This causes work to be rushed, which in turn causes tasks to be commenced without all inputs or prerequisites, leading to low efficiency, task interruption, and increased variability (degrading our ability to predict an outcome – hence the importance of the theory). Likewise, controlling by means of a performance baseline that is no longer based on actual status becomes ineffective, or simply counterproductive, and results in the customer needs not being met. When we fail to meet customer needs, it’s impossible for us to achieve project success.
For that reason, some discussion of the conceptualizations behind the theory is warranted before discussing the fundamental considerations. The benefits of using a theory, in the context of conducting a project, are that the practical actions derived from the proper implementation of the theory can help us achieve our goals. I would start by establishing three levels of goals for any project: first, there is the general goal of getting the intended deliverable completed; second, there are technical (or internal) goals, such as cost minimization and adhering to a schedule, that means the project has been done right; and third, there are customer satisfaction (or external) goals, such as quality and functional utility, that means the right project was done right. By applying project management theory, we can (hopefully) dramatically improve the likelihood of reaching the third, and ultimate, goal.
To begin, project management is about managing work. Turner (1993), claims that work can be managed by decomposing total work into activities and tasks – that’s the basic concept. As the PMBOK Guide shows, these activities and tasks are the unit of analysis in the core processes of project management, such as scope management, time management, and cost management. Morris (1994) supports this description by outlining a project management approach based on four steps: first, what needs to be done; second, who is going to do what; third, when actions are to be performed; and fourth, how much is required to be spent in total, how much has been spent so far, and how much still has to be spent. Central to this sequence is the Work Breakdown Structure (WBS), which is a key deliverable of the project planning process, and is crucial to scope management and project control.
The PMBOK Guide provides us with a second concept in project management, by laying the groundwork for planning progression. Ten core processes, including scope planning, scope definition, activity definition, resource planning, activity sequencing, estimating, and project plan development, have been identified to guide the planning process. The outputs from these processes are the project plans, which form the inputs to the execution processes. The implication here is that if you effectively complete these steps, you’ll have the necessary inputs for successful execution, which will lead to a successful project.
These two primary concepts – the project as a series of tasks and activities, and the core planning methodologies as guiding principles – can help us understand a general theory of project management, which is thus: by undertaking a series of sequential, yet interrelated, tasks to define, plan, prepare and execute a project, you will be able to effectively achieve technical success and customer acceptance.
Although this theory sounds relatively simple, we often find that organizations have trouble putting the concepts into practice. Some of the key reasons are a combination of limited resources, lack of understanding, and the perception that there are no immediate financial benefits to justify the time spent on project management (i.e. it’s a cost-center). More specifically, young organizations view formal project management as overly bureaucratic, and as a hindrance to getting business done. Yet, these organizations are the ones who can most benefit from the application of theories that improve structure and accountability – which are direct results of the two key concepts discussed above.
Additionally, the theory of project management helps organizations gain efficiencies through standardization and streamlining. An organization that understands their own business, by analyzing and consistently following the core processes, can lower costs and enhance service levels. These core processes can be documented, allowing the organization to work on ways to improve the work-flow and customer experience at each stage. This feedback loop creates a virtuous cycle: documenting the steps to produce a deliverable will lead to more consistent application of the processes, which leads to more standardization, then to continuous improvement, and then back to documenting the improved steps.
Furthermore, by increasing consistency, deviation rates will decrease and you will find improvements in predictability – lending credence to the theory suggested above that by breaking a project down into tasks and following the core planning methodologies, we can create a plausible expectation of the outcome. This application of project theory also provides more accurate measures of project progress, which enhances our ability to meet project goals.
By ignoring the fundamentals of project management theory, especially during the planning stages, we find that customer requirements are poorly defined, and the process of clarifying and changing requirements leads to disruption. This is one of the key reasons that projects fail – incomplete or inaccurate scope definition. The constant disruptions cause actual progress to drift from the plan, which becomes too burdensome to regularly update (adding to the perception that project management is overly bureaucratic).
Without an updated plan to work from, informal management becomes prevalent. This causes work to be rushed, which in turn causes tasks to be commenced without all inputs or prerequisites, leading to low efficiency, task interruption, and increased variability (degrading our ability to predict an outcome – hence the importance of the theory). Likewise, controlling by means of a performance baseline that is no longer based on actual status becomes ineffective, or simply counterproductive, and results in the customer needs not being met. When we fail to meet customer needs, it’s impossible for us to achieve project success.
Thursday, January 15, 2009
A New Constraint
Going through project management courses, I've become intimately (if not sickeningly) familiar with the so-called "triple constraint" of time (AKA schedule), cost, and performance (AKA quality or scope). The basic idea here is that there is a balance, and a trade-off, between these three factors that is necessary to successfully complete any project. I even remember telling my old clients (back when I was doing some consulting work) that they could choose any two (i.e. time and scope; scope and cost) but their choices would influence the third, which was under my control (i.e. if they wanted to dictate time and scope, then I got to tell them the cost; if they wanted to control cost and scope, they had to work on my schedule). This concept is so ingrained into the project management mentality that I assumed there wasn't much left to discuss about project constraints. So imagine my surprise, fellow thinker, when I learned of a bright, shiny, new (to me at least) fourth constraint - customer acceptance!
Customer acceptance is a constraint that can change the way we view our role as a project manager. It forces us to think outside of technical success and shift to more of an outward focus on customer requirements. In this manner, it also increases the importance of communication and understanding during the conceptualization and planning phases - what good is a project that comes in on-time, on-budget, and meets the design criteria if the customer isn't satisfied?
In a way, this new constraint reminds me of a topic in quality management. Quality is a term that really has two definitions: one is the objective view of how well the product conforms to design standards; however, the more important measure of quality is the subjective measure of how happy the client is with the final product. In projects, the triple constraint is basically the technical criteria. But it's this fourth constraint that adds a subjective perspective and says that a project isn't truly successful unless the client says it is.
The idea of a fourth constraint lends itself to another topic from quality management - Quality Function Deployment. QFD uses the "Voice of Customer" (VOC) to thoroughly and accurately define the requirements of a product. Once identified, those requirements are translated into design requirements, which are then translated into engineering requirements. This flow-down ensures that the "how's" from one level become the "what's" at the next level and sight of the original customer "what's" is never lost.
So the fourth constraint is vitally important to any project team, and serves as a bridge between the technical and the subjective measures of project success. And it's about time that someone has defined this link and clearly articulated the importance of the customer in an existing model. I know that I'm sometimes guilty of focusing too much on the internal aspects of a project. Changing the mindset of a PM to look at all four constraints should have a substantial positive impact on performance.
Customer acceptance is a constraint that can change the way we view our role as a project manager. It forces us to think outside of technical success and shift to more of an outward focus on customer requirements. In this manner, it also increases the importance of communication and understanding during the conceptualization and planning phases - what good is a project that comes in on-time, on-budget, and meets the design criteria if the customer isn't satisfied?
In a way, this new constraint reminds me of a topic in quality management. Quality is a term that really has two definitions: one is the objective view of how well the product conforms to design standards; however, the more important measure of quality is the subjective measure of how happy the client is with the final product. In projects, the triple constraint is basically the technical criteria. But it's this fourth constraint that adds a subjective perspective and says that a project isn't truly successful unless the client says it is.
The idea of a fourth constraint lends itself to another topic from quality management - Quality Function Deployment. QFD uses the "Voice of Customer" (VOC) to thoroughly and accurately define the requirements of a product. Once identified, those requirements are translated into design requirements, which are then translated into engineering requirements. This flow-down ensures that the "how's" from one level become the "what's" at the next level and sight of the original customer "what's" is never lost.
So the fourth constraint is vitally important to any project team, and serves as a bridge between the technical and the subjective measures of project success. And it's about time that someone has defined this link and clearly articulated the importance of the customer in an existing model. I know that I'm sometimes guilty of focusing too much on the internal aspects of a project. Changing the mindset of a PM to look at all four constraints should have a substantial positive impact on performance.
Sunday, December 28, 2008
Value Reversion
So I'm just finishing up a course on cost and value management in projects, and I got to thinking about value creation. More specifically, what types of value do projects create for an organization? My initial thought was that myriad types of value can be created - increased productivity, reduced loss, enhanced brand awareness, improved quality, increased sales, etc. The outcome of a project designed to achieve any of the preceding objectives is an increase in value for the firm.
However, we all know that goals and objectives have to be measurable to be meaningful. And pretty much anything that can be measured can be quantified. Improving quality may be the project objective, but quality has to be defined in real terms, not just as an abstract concept. For example, if quality means less waste, then the performance indicators for your project are the amounts of waste produced. As waste is reduced, value is created.
So if you can quantify the value, won't it always be possible to convert it back into monetary terms? If you're measuring the amount of waste, it's good business to know what that waste is costing you - I mean, that's really the business case for undertaking the project in the first place. The same holds true for any project objective. Viewed in these terms, value always reverts to money. And if you can't revert value back to dollars, I'd venture to say that you either aren't measuring performance correctly, or that the project really isn't creating any value.
However, we all know that goals and objectives have to be measurable to be meaningful. And pretty much anything that can be measured can be quantified. Improving quality may be the project objective, but quality has to be defined in real terms, not just as an abstract concept. For example, if quality means less waste, then the performance indicators for your project are the amounts of waste produced. As waste is reduced, value is created.
So if you can quantify the value, won't it always be possible to convert it back into monetary terms? If you're measuring the amount of waste, it's good business to know what that waste is costing you - I mean, that's really the business case for undertaking the project in the first place. The same holds true for any project objective. Viewed in these terms, value always reverts to money. And if you can't revert value back to dollars, I'd venture to say that you either aren't measuring performance correctly, or that the project really isn't creating any value.
Subscribe to:
Posts (Atom)