Agile, Waterfall, Scrum & Enterprise Project Management
With the velocity being created by the Agile movement it is important that we take a moment to clarify a few things. First, Agile is not a standard of any sort. It is a movement that consists of a 73 word manifesto and 12 principals. The manifesto and its principals as written can only truly be applied for the optimization of software development Projects. That said, the spirit of both can be applied more broadly and have been honored in the 120VC Project Management Standard.
Waterfall was invented by a computer scientist named Winston Royce in the 1970’s when he wrote a paper called “Managing the Development of Large Software Systems”. The approach was specifically designed to optimize the development of Software Systems given the technology that was available at the time. In a nutshell, the article outlined how software development should be completed in phases and that no work in a subsequent phase could be completed until all of the work in the current phase was done.
At no time was the Waterfall methodology adopted by the Enterprise Project Management community as it would be the least efficient way to complete a large scale Project with multiple matrix, cross disciplined teams and external vendors.
We define Enterprise Projects as those that require multiple matrix, cross disciplined teams and sometimes external vendors to complete. Enterprise Projects require that communication, and cross organization dependencies be managed tightly to ensure that contributors on one team are ready to start work as soon as the dependent work is completed by a member of another team. Enterprise Projects cannot be completed by a single group of fully dedicated people with a single discipline.
Traditionally, the critical path method has been used on Enterprise Projects. The concept of critical path assumes that there are multiple work streams being executed in parallel on every project; and that given the cost and schedule constraints of most organizations, the schedule of each of those work streams has been compressed or “crashed” to ensure that no time or money is being left on the table.
In the waterfall model, there would only be a single work stream and all of the work would be on the critical path.
Therefore, when people talk about Agile or Waterfall they are talking about frameworks, not step by step standards; and neither of these frameworks have anything to do with traditional Project Management outside the realm of software development.
Scrum is a software development standard that has many well documented step-by-step best practices that can truly optimize an organizations ability to frequently deliver working software. I personally recommend “Agile Project Management for Dummies®” written by Mark C. Layton and published by John Wiley & Sons, Inc. It is a well-documented, easy to follow approach to Agile software development.
Scrum best practices create velocity by requiring a dedicated development team that defines tasks no longer than 1 day in duration, and meets daily to assess progress. With a dedicated team and work broken down into single day increments, it becomes very easy to see where changes need to be made to increase the productivity of the team.
Enterprise Project Management works with matrix teams, breaks tasks down into a maximum of 12 hour increments, and uses the critical path to forecast the impact of progress, lack of progress and risks to make data driven decisions today. This controls the future outcome to ensure the closest possible delivery of the project to the planned end date and cost.
In my humble opinion, Scrum is the most efficient way to develop working software. When a development organization is truly optimized using Scrum best practices they are not leaving any time or money on the table. The only downside to Scrum is that it completely ignores a companies need to allocate funds and resources from Projects with surplus to Projects in need in a Program or Portfolio. In addition, it doesn’t account for or support the cross organizational dependencies on an Enterprise Project.
What that said… 120VC recognizes that Scrum is the hands down winner when it comes to software development and that the Agile principals can be used to optimize any Project Management Standard. Therefore, the 120VC Project Management Standard has been optimized to leverage each of the Agile Principals in the context of an Enterprise Project and we are working on an Agile Addendum. The addendum is a Standard that allows outputs from a Scrum Project to be used as input into an Enterprise Project to achieve three things:
- To overcome Scrums inability to support Program & Portfolio needs.
- To allow Scrum outputs to be used to efficiently manage cross organizational dependencies, and…
- To allow for the allocation of funds and resources from Scrum Projects with surplus to those in need.
Of the many very valuable Scrum best practices, there are only two that can’t be adopted by Enterprise Project Management. The first is the practice of having dedicated teams and the second is the practice of “just in time” planning.
Enterprise Projects will always use matrix resources or “non-dedicated” resources. Consider this… If you have a Portfolio with 200 projects that need to be completed in a given year, let’s assume that at least 100 of them are Enterprise Projects and each will take 1 year to complete.
In this scenario there are only 20 people available to work on your projects across the functional teams, therefore each will be assigned to work on 5 projects at a time. If you were to staff each of these projects with dedicated teams you would need to add 80 people for a total of 100. Dedicating resources would allow you to complete all 100 projects in 1/5th the time or in approximately 2.5 months. This would increase the rate of change across an Enterprise by 5X. This amount of change is not sustainable and would leave your organization with two unrealistic options:
- You would have 80 employees with no work for the remainder of the year that you could keep to retain your domain knowledge or lay them off.
- You could increase the number of projects you deliver from 100 to 500 in a year, but first ask yourself how well the change associated with 100 is being digested.
Enterprise Projects actually do employ the use of “just in time” planning. The difference is that “just in time” has a different meaning on a development Project with no cross organization dependencies and a dedicated team vs. an Enterprise Project.
Agile projects identify the requirements at the beginning of each Project, but wait to plan out the tasks associated with their users stories at the beginning of each sprint. This can be done because the resources are dedicated and available to work on whatever is decided in each sprint planning meeting.
Enterprise Projects compete for matrix or “un-dedicated” resources. If you don’t book them in advance based on a timeline developed with predecessor successor relationships, they will NOT be available when you need them to start. Therefore, “just in time” planning on an Enterprise Project is at the beginning.
Last note here… Another Agile principal is “Responding to change over following a plan”. This principal can be adhered to even if you create your entire plan at the beginning of a Project. On Enterprise Projects change is driven by two things:
- Risks, and…
When a Risk arises that can only be overcome by changing the scope, we change the scope! When a request comes in to change the scope… We change the scope!
This is one of the areas that the Agile best practice “Inspect and Adapt” comes into play. If there is an obstacle to completing the Project that can only be overcome by changing the scope, then “good customer service” dictates we do this. If either a Project Owner (Enterprise Project) or a Product Owner (Agile Project) wants to change the scope, they are making this decision because they feel it will benefit their customers or Project beneficiaries.
The only difference between the Change Management Process on an Enterprise Project and an Agile Project is that once the change is requested, whether it is due to a Risk or a Request, the Project Manager assesses its impact to the overall Project Cost and Schedule. This doesn’t impact the Project team’s productivity at all because they continue to complete the tasks committed while the assessment is completed. In addition, there is an Enterprise Project best practice that requires this assessment takes no longer than 10 days.
Once the assessment is completed the impact (if any) is presented to the Project Owner or Product Owner so they can make an informed decision. This is done because all changes are perceived to be great ideas, and all changes are requested without any data on how those changes would impact Project Cost and Schedule. All the “Change Assessment” process does to ensure Project and Product Owners are making COMPLETELY informed decisions.
Program Management Effectiveness: Managing Program Risk
Program Managers spend their days working with their Project Managers to mitigate the Risks that surface on their projects. This article will focus on two simple Program Risk Management Tools. The first tool is the “Late Finish Date”. The Late Finish Date is the latest date that a Risk can be solved before it begins impacting the Project finish date and cost. The Late Finish Date or Late Date is calculated automatically by most Project Management Tools and can be added to any Work Plan simply by adding the field to your view.
As most Projects have at least one Risk on any given day, a Program Manager can become overwhelmed trying to decide which Escalation they should take ownership of and which they should allow their Project Managers to continue to solve on their own. The “Project Manager that screams the loudest” approach to prioritization isn’t always the best way to ensure a Program Manager is working to mitigate the highest Risk in their Program.
The Late Date makes it easy… For example: If a Program Manager had 5 Risks across their Program: One with 5 days to solve before it began impacting its Project’s End Date and Cost, another with 10, another with 20, another with 30, and the last one with 6 months to solve, the Risk with 5 days to solve before it begins impacting the Project end date is obviously their highest priority.
Integrating the Late Date into a Program Manager’s tool kit is as simple as requiring their Project Managers to ALWAYS communicate the Late Date with the description of the Risk and the solution they are proposing. When a Late Date is not provided, the Program Manager should request one be provided before attempting to prioritize the Risk being escalated.
The second super simple tool will eliminate almost 100% of a Program’s “Avoidable Risks”. We define Avoidable Risks as things like poor resource loading across a Program or Organizational Politics. We define “Unavoidable Risks” as those that could not be foreseen due to the complexity or uniqueness of a Project.
Most Project Contributors are assigned to several Projects at a time and have daily operational responsibilities. Therefore, most Contributors generally have more work than can be completed in a 60 hour week with competing priorities. Program Managers should require that their Project Managers manage to their critical path by educating their contributors on the slack associated with each task assignment. Contributors should be taught that tasks with little or no slack CAN NOT finish late without causing the Project to end late. Providing this information to contributors will allow them to effectively prioritize their weekly task assignments by prioritizing those tasks with little or no slack above all else.
Who would intentionally deprioritize a task that will turn a Project Yellow or Red?
Requiring Project Managers to manage to the critical path and enforcing it is simple! First, have your Project Managers add the “Total Slack” to the view in their Work Plan. Then, just be sure to ask the Project Contributors with whom you interact while mitigating Project Risks if they were informed that their task was on the critical path during their last weekly status meeting. As the Contributors start to realize they can use slack to prioritize their workload, they will start asking their Project Managers to provide them with this information at the time the task assignment is made.
This approach to managing to the critical path will eliminate almost 100% of the “Avoidable Risks” and free a Program Manager to focus on the top priority Risks as determined by the Late Date.
Intuition does not come to an untrained mind. It is important to note that Program Management Tools will never replace the need for a Program Manager to think critically and Lead effectively. They are meant to give the Program Manager additional data that can be used to increase the effectiveness of their critical thinking and leadership efforts. Without data, intuition is bankrupt.
When introducing the “Late Finish Date” and “Management to the Critical Path Using Slack” to your organization, remember that 80% of education provided by corporations to their team members is lost. Behavioral change must be championed regularly by Senior Leadership and reinforced daily by managers. Our tip to successfully implementing these simple tools is to take a top down approach by follow the next three steps:
- Share the benefits with Senior Leadership and get their buy-in.
- Work with Senior Leadership to train and get buy-in from the Program Management Team.
- Train your Project Managers and Contributors on the benefits and expectations. Be sure to follow the steps in the article above to hold them accountable.
We DO NOT recommend the alternative, taking a bottom up approach. A bottom up approach where you start with the Project Managers and Contributors will likely result in a training session that gets every Project Manager talking about the critical path, but not actually employing it to minimize the avoidable risks. Essentially, it will result in a rebranding exercise with no real change.
Special thanks to Susan Black, Chris Baker, and the 120VC Program Management Steering Committee for their contribution to this article! You guys rock!
Program Management Effectiveness: A Case Study on Rapport
When you boil it down… The PURPOSE of a Program Manager is to ensure all of the Projects in their Program are completed and that the budget allocated to the Program is not exceeded. To succeed at this, Program Managers need to accept that, regardless of how thoroughly each of their Projects are Planned, Risks will occur on each of the Projects in their Program every day.
A Program Manager’s job is to ensure the Risks that are occurring are not due to a Project Manager’s lack of competence; that their Project Managers are actively identifying all Risks and driving mitigating strategies that move their Projects closer to completion as aggressively as possible. Typically, there are 3 categories of competence that a Project Manager will fall into:
Type 1: Performing.
Type 2: Lacks the experience to make the most aggressive decisions, but takes directions and learns quickly.
Type 3: Lacks the Aptitude or Attitude and is a Risk to the Project.
Program Managers are also responsible for performing Program analysis to identify opportunities to allocate funds and resources from Projects in their Program with surplus to Projects in need. This is done to ensure that all of Projects in their Program can be completed as scheduled, and that the funds originally allocated to the Program are not exceeded. Essentially, a Program Manager:
- Assesses and eliminates any Risk to the Projects in their Program associated with Project Manager Competence.
- Quality assures their Project Managers’ work to ensure that their reporting can be effectively used to perform the required Program Analysis, that Risks are being mitigated, and that each of their Projects are moving closer to completion as aggressively as possible.
- Completes weekly Program Analysis to identify opportunities to allocate funds and resources across their Projects to ensure each completes according to schedule, and to mitigate any Risk to the Program budget as aggressively as possible.
During a study of Project Managers at 120VC, we found that there were two distinct reasons a Project Manager would end up categorized as a Type 3, Attitude or Aptitude. In some cases Project Managers were perceived to have the Aptitude to control the cost and schedule of their Projects; they just chose not to do the work!
First, we assessed the Type 3 cases related to Aptitude and found ways to eliminate the Risk associated with identifying them after being assigned to a Project. The following measures were taken to reduce the number of Aptitude cases to almost zero.
- We improved our screening and interview procedures to focus on Aptitude in addition to past experience, qualifications and references. We found that past experience, qualifications and success are all subjective qualifications that ALL candidates view and present in a positive light. However, Aptitude can be objectively measured with very little room for error. And…
- We educated our employees and customers on our Zero Trade Off policy. In essence, when our clients have a need to start a Project they are being pressured by their organization to provide a Project Manager YESTERDAY, and to begin their initiative immediately. Under the pressure to satisfy a customer’s immediate need, our Account Teams have occasionally assigned a Project Manager that was less than qualified. Sometimes knowingly and other times due to a rushed qualification process. In all cases, Trade-Offs where consciously made.
The client, in a rush to start their initiative would accept the less than qualified candidate; again, sometimes knowingly and other times due to a rushed qualification process. Essentially, The Trade-Offs created a Type 3 – Aptitude, and put the Project Manager, the Client and 120VC in a position to fail.
To address the Trade-Offs, we created a culture through education that made our Account Managers and Program Managers comfortable passing on an opportunity, rather than rushing the qualification process and assigning a Project Manager that didn’t have the Aptitude to be successful.
We educated our clients to ensure they understood our rationale for passing on opportunities or being slow to produce qualified candidates. 120VC will not take on an engagement unless we have, or can find, a qualified Project Manager to assign and create a WIN, WIN, WIN scenario; a WIN for the Project Manager, the Client and 120VC.
While assessing the Type 3 due to Attitude, we found that almost no one shows up to an interview with a bad attitude, or shows up to the first day on the job with a bad attitude. However, everyone is capable of developing a bad attitude. So there was no way to identify a Type 3 – Attitude before assigning them to a Project.
In further analysis we found that in almost every case where there was a Type 3 – Attitude, the Project Manager had more rapport with the Client, Project Owner or Sponsor than the Program Manager had with them. Essentially, the Project Manager was confident in their ability to control the narrative with the client, and was certainly not representing themselves as a Risk.
In each of these cases, the Program Manager was working behind the scenes or attempting to insulate the client from the Risks being created by the Type 3. The Program Manager was not partnering with the client, keeping them abreast of the Risks being created by the Project Manager, the steps being taken to eliminate them, or taking the time to build rapport. The imbalance of rapport eliminated the Program Manager’s ability to manage the Type 3.
This led us to analyze the Client / Program Manager relationships associated with Type 1 & 2 Project Managers. In each case the Program Manager had “Good to Excellent” rapport with their client. We found that Program Managers with “Good to Excellent” client relationships rarely encountered a Type 3, and when they did it was usually a Type 3 – Aptitude.
In addition, the Program Managers that had “Good to Excellent” rapport with their clients had fewer challenges with Type 3 – Attitude due to over-allocation. This is because their clients were following the 120VC Work Intake process and working through the Program Manager to assign work to 120VC personnel. In scenarios where the Program Manager had less than adequate rapport with their clients, the Project Managers were generally over-allocated.
In these cases, the client would approach the Project Manager with new work assignments due to their rapport and the Project Manager would accept the work due to their rapport. The lack of Program Manager rapport caused a breakdown in the Work Intake process and led to Trade-Offs that impacted the Project Manager, Client and 120VC.
In summary, our study showed that in order for a Program Manager to ensure all of the Projects in their Program are completed, and that the budget allocated to the Program is not exceeded, they need to employ the “Rapport Tool”. The Program Manager will also need to be effective at identifying Risk, Analyzing the Portfolio, etc… However, unless the Program Manager has “Good to Excellent” rapport with their client, they will not be able to effectively do their job.
How to Avoid the Roadblocks Created by Methodology & Complete Planning ASAP!
As a Project Management Professional, I learned long ago that our clients have little tolerance for the planning involved when they engage a Project Manager, and all anyone associated with a Project really wants to do is start the work. They believe that the sooner they start the work, the sooner they will finish the Project.
In addition, most clients have an abundance of standard deliverables outlined by their methodology that are lightly documented and may or may not be required on every Project. The lack of clearly documented and subjective deliverables creates DRAG, and results in Risk to completing planning as soon as possible.
Recognizing that our client’s methodologies are intended to control portfolio pipeline, support financial allocation, resource staffing / allocation, and provide data to facilitate executive stakeholder decisions, the identification and execution of their processes and associated deliverables is just as critical as the actual Project work.
– A Project Manager needs to complete Planning as soon as possible.
– Identify and execute all of the standard deliverables required by their client’s methodology.
– Eliminate any DRAG associated with standard client deliverables that are lightly documented and subjective.
– Eliminate the Risk associated with late-breaking requirements and avoid spending time each week debating about which standard client deliverables and Project Management Best Practices are required, and…
– Prevent Project Team members from asserting mid-planning process requirements to avoid task assignments.
To do this, the Project Manager must identify the standard client deliverables during the First Week of the Project and incorporate them into their Planning Schedule. Then the Project Manager must obtain consensus from the Project Owner and Executive Stakeholders on which are required for each Project. Once consensus is obtained the Project Manager can escalate any process disagreements to the Project Owner for resolution, and keep the team focused on completing Planning as soon as possible.
To do this we recommend, and take the following steps during the Planning Schedule Approval Meeting:
1. Walk the Project Owner and Executive Stakeholders through the Planning Schedule task by task.
2. Review the standard client deliverables the Project Owner feels are unnecessary, the reasons for their durations, their PURPOSE and VALUE.
3. If the Project Owner feels any of the standard client deliverables are unnecessary after the review, remove them.
4. If after review and removal of the unnecessary standard client deliverables the Project Owner feels the duration for planning is too long, review the reason for the durations of all of the tasks, their PURPOSE and VALUE.
5. If the Project Owner feels the durations for any of them should be reduced, reduce them.
Wisdom comes with experience…
If the Project Owner insists on an unrealistic completion date for Planning after going through all of the steps above there is a reason. DO NOT ARGUE THE POINT, “zip it” and AGREE! You will simply manage to the dates, keep the Project Owner informed of progress, Risks, and their solutions to achieve the fastest possible result. If you push hard, communicate effectively, and focus on developing and driving solutions to Risks, you will be perceived as having done everything possible to complete planning by the due date, and the Project Owner will be more than satisfied with your performance – even if you miss the date!
Remember, effectively LEADING the Project Owner is an essential element of creating a platform for success!
Management of the Project Budget – Are you getting what you’re paying for?
Effective management of a project’s budget begins by managing and accounting for the Projects spending, and establishing a Baseline Budget once the Planning Documents have been established. When a Project Manager is assigned to a Project, two things are generally true.
1. Someone has created an estimated budget for the Project and communicated that fabricated number all the way up the food chain. And…
2. Just like project work generally begins before the Project Manager is assigned; funds are also spent. At a minimum the cost of the Project Manager begins accruing on the first day and must be tracked and reported to the Project Owner weekly.
As we all know, there is a huge emphasis in the Project Management Community about the management of Project Budgets. In fact, some of our basic principles like the “Triple Constraint” teach us to assess Risk in association with Cost, Schedule and Scope.
Unfortunately, most organizations that I encounter want the Project Manager to rely on the reports produced by their Finance Departments. Given the inherent limitations of these departments ability to gather accurate, project specific data, there is no real way for the Project Manager to use these reports to identify Issues or Risk associated with the Project Budget.
The reports provided from the Finance Department only reflect the spending associated with invoices received by their organization. They do not reflect the Project funds that have been committed to vendors for goods shipped or services rendered but not yet invoiced. They certainly don’t reflect the lost invoices, the invoices sent to the wrong email address or the invoices sitting on the desk of Mr. “I Haven’t Had Time”!
Simply put, without knowing exactly what has been Spent and Committed, there is no way for a Project, Program or Portfolio Manager to identify Issues, assess Risk or make informed decisions to ensure they don’t go over budget.
In my experience most Project Owners don’t care about impact to Scope if there is no impact to Cost. Sometimes there is concern about impact to the schedule even though there is no corollary impact to cost, but, if you want to see someone lose their mind… tell them you are going to go over budget!
In addition to closely tracking what is spent on a Project, it is important for the Project Manager to develop a Baseline Budget after the project has been planned. This is done to verify the accuracy of the original budget estimate. Without this step there is no way to know if what was planned can be completed for the amount that has been set aside.
By developing a Baseline Budget, the Project Manager can provide the Project Owner with the information necessary to stay within the original estimate by cutting scope or to obtain the funds necessary by using the Project Plan to substantiate the actual cost.
Without this step, there is no way to know if the decisions you are making about how to spend your funds will prevent you from going over budget because the estimated budget you would be tracking against could be wrong! Essentially, the decision to skip the establishment of a Baseline Budget and rely on someone other than the Project Manager to track your spending, will severely limit your ability to Manage the Project Budget.
The Role of the PMO – Are you achieving the value?
I believe we are in agreement as a community that the role of the PMO is to ensure the consistent application of an organization’s methodology and processes across the portfolio. What I don’t hear anyone talking about is why… Organizations launch PMO’s because the CIO and the CFO want to be able to make data driven decisions about how to allocate funds and resources across their portfolios to achieve the greatest return for their investment. Essentially, a project portfolio is no different to them than a financial portfolio.
Ideally, both the CIO and CFO would receive a weekly or monthly fact based report from the PMO that lists each project in the portfolio with a summary of their health in relation to the project end date and cost. This information would then be used to make decisions for the reallocation of funds to projects over budget from projects under budget as well as the allocation of resources from projects ahead of schedule to projects behind schedule. Just like an investor would make buy / sell decisions based on the report provided by the finance manager.
PMO’s have turned to implementing PPM systems at significant cost and impact on the organization in an effort to provide reports. The problem is the consumers of these reports don’t trust the data! This is evidenced by the weekly or monthly status meetings that every Project Manager has to attend to talk about their projects with executives who have already received the report. This meeting takes place because the executives are attempting to validate the data in the report before making any decisions because they don’t trust that Red is Red or Green is Green! Often, they require very detailed financial reports for each of their projects in order to perform their own financial analysis before making decisions. This type of work does not make “O” level executives happy or build their confidence in the PMO.
We have now come full circle to the role of the PMO… The reason PMO leaders need to ensure the consistent application of their methodology is so their CIO and CFO don’t need a secret decoder card, 10 meetings per month and a private detective to get the data they need to make decisions.
Today, PMO leaders spend most of their time implementing or refining their methodologies because their CIO and CFO are unhappy with their ability to achieve the ultimate goal of the PMO; Consistency of Project Management approach, assessment of risk / project health, financial analysis and status reporting. Each new change or refinement made by the PMO requires training and adoption during which most Project Managers are not consistently adhering to the set standard. This cycle of constant change is the number one contributor to the lack of consistent application of an organization’s methodology across their portfolio.
The second major contributor to a lack of consistency in Project Management approach across projects is that Project Managers do not need to adhere to a standard methodology to get a project done and be successful in the eyes of the stakeholders. Furthermore, their customer is generally the person in the line of business, IT, or the home owner that is looking forward to having the project done, not the CIO or CFO. Roughly translated, the chaos created by the constantly changing, rarely documented methodologies, that aren’t really tools to help the Project Manager succeed in completing their projects, are generally viewed by Project Managers as unnecessary overhead.
There is good news… The solution to this problem is simple and cost effective. Find a company that is in the business of Project Management and that has successfully developed and uses a methodology or tool kit for your type of projects. Adopt it. Don’t create overhead for yourself by changing it. Train your teams and then spend your time quality assuring their work instead of constantly reinventing project management. The focus on quality assurance will provide you with the consistency you need to provide reliable data to your CIO and CFO. It will also eliminate the cost of methodology maintenance, offset the cost of training vendors and establish a partnership with a company that can provide you with staff augmentation that doesn’t need to be trained in your Project Management methodology.
In other words, buy a car that runs and drive it. Only a masochist purchases a car that needs constant maintenance and that will not serve its primary purpose: to and fro.
If you care to share your perspectives on this topic or if you have a different point of view, please contact me directly. I would love to discuss this topic with you further.
Rebranding vs. Adopting – A Dangerous Trend
As Project Managers we talk a lot about Methodologies and Standards. As leaders of Project Management organizations we spend a lot of time developing inter-organizational project management centers of excellence. All of this activity is indicative of two things. The first is a perceived need for organizations to improve their ability to control cost, schedule and produce a ROI; the second is the belief that Project Management disciplines are the way to accomplish this.
The fact is the Project Management trade as a whole is floundering at a CMM Level 1¡ at best. Most organizations’ Project Management Methods are lightly documented, if at all, and in a state of dynamic change, tending to be driven in an ad hoc and reactive manner. In addition, most organizations approach project management differently. Experienced, previously successful Project Managers are hired and asked to re-learn their trade according to their new employer’s point of view.
Management approaches come and go like shiny new objects. I believe that Project Management is here to stay simply because there have been pockets of large scale success that organizational leaders cannot turn their backs on. It is proven that thorough planning provides the ability to forecast impact of progress, lack of progress and issues to project end date and cost. Forecasting allows the quantification, prioritization and the development of appropriate responses to risk so project executives can make informed decisions.
In order for organizations, and the Project Management trade as a whole, to achieve the successes that have been proven to result from disciplined Project Management techniques, we need to take the time and put in the effort to actually adopt them. Today’s trend in the development of Project Management centers of excellence is identifying the latest shiny new object (SCRUM, LEAN, PMBOK) and then completely customizing it to fit the organization. What generally results is a re-branded version of what the organization was already doing. When the organization fails to realize a ROI from the Project Management discipline that was not actually adopted, the failure is blamed on the standard and another shiny new object is identified.
Real change takes discipline and time. There are no short cuts to quality, and customization has proven to give us more of what we already had. There is a reason our Project Management standards exist. It is because they have yielded results. The adoption of external standards in their entirety would eliminate the re-education of Project Managers each time they take a new job. Not only would organizations finally yield the proven results from Project Management and move our trade up the CMM ladder, they would be able to hire professional Project Managers who can accomplish this from any source.
In the end, customization is about our comfort level. Real change is not comfortable, but necessary if there is a real need to improve. Rebranding is not adopting.
If you care to share your perspectives on this topic– or if you have a different point of view – please contact me directly. I would love to discuss the topic with you further.
Project Management – Leaders vs. Note Takers
As Project Managers we learn how to facilitate the definition of the project scope while working with the Executive Stakeholders. We also learn that in order to properly plan a project we must work with subject matter experts as facilitators while they identify the necessary project tasks.
Essentially our job is to identify what the Executive Stakeholders would like delivered and then work with the subject matter experts to have them identify the tasks necessary to give the stakeholders what they want. Once the work is started we gather and report status.
What is often overlooked is the leadership aspect of those exercises. Simply documenting Executive Stakeholder requests without questioning until you truly understand their stake, the benefits / impacts to their organization, and their concerns will eliminate your ability to identify conflicts between stakeholders, obtain buy-in from each and develop a unified defensible understanding of what you need to deliver.
At the end of this exercise the Executive Stakeholders should have bought in to a single mission and the Project Manager should possess a level of clarity that will allow him to judge the best approach and the appropriate tasks when provided by the subject matter experts.
As the Project Manager facilitates the identification of Project tasks, the same level of diligence described above should be taken to ensure he develops a thorough understanding of each task, its predecessors, successors and breadth. Though each task must be identified by the appropriate subject matter expert, the Project Manager must judge its applicability to the completion of the defined scope.
Subject Matter Experts are better suited to identify the tasks they will be responsible for completing than the Project Manager, and it is much easier to hold someone accountable for the completion of something they identified as necessary. However, simply documenting each task provided without gathering the appropriate information to judge its applicability will eliminate the Project Managers ability to support and defend the final approach and schedule to stakeholders; to identify and prioritize the resolution of issues, to develop risk mitigation strategies and judge the impact of scope changes during the course of the project.
In summary, the Project Manager who simply documents stakeholder requests, contributor recommendations and status without due diligence will not have the understanding or credibility necessary to “lead” their stakeholders and contributors to success.
If you care to share your perspectives on this topic with me – or if you have a different point of view – please contact me directly. I would love to discuss the topic with you further.
Communication Skills – A Means To An End
When interviewing Project Management candidates, I often ask what three attributes a Project Manager should possess. In response, one of the three attributes is almost always “strong communication”. This answer surprises me since communication is simply a means to an end. Communication is the vehicle in which we deploy all of our attributes or skills, but it is not our final destination.
When analyzing this response I realize that our Project Management community emphasizes strong communication as the most important attribute a Project Manager can possess. I believe the question that needs to be answered is: Why do we need strong communication skills?
As Project Managers we communicate to accomplish a singular goal; to complete our projects and achieve the highest degree of success possible for our stakeholders. In order to do this we must develop relationships and lead. We accomplish this by communicating. We can’t lead or build relationships silently.
Many of us have encountered “the project that never ends”. This problem occurs when the project team and stakeholders are completely focused on the “means” rather than achieving results. It is the Project Manager’s job to move the team forward by encouraging them to make decisions and then holding them accountable to the results.
Likewise, to improve our success as Project Managers it is important to focus our development and education on the attributes that will ensure our success; up, down, and across leadership and relationship building. We must focus on the “end” rather than the “means”.
I agree with Ralph Waldo Emerson who said “life is a journey, not a destination”. However, Project Management is about the results, not the journey.
In summary, we communicate so we can lead.
If you care to share your perspectives on this topic with me – or if you have a different point of view – please contact me directly. I would love to discuss the topic with you further.
Project Management Methodologies – The Brands, The Myths, The Legends
As the CEO of a project management consultancy, I am in the business of providing project management expertise to those who don’t have it. During the process of planning and completing projects we also act as emissaries for our trade, raising awareness and educating our customers so they can obtain the greatest value from their investment in project management.
Educating our customers also helps them avoid the costly mistake of investing in training, products, vendors, or individuals that will not improve their ability to control costs and complete projects on time. While carrying out this mission my team and I have found that there is quite a bit of confusion with respect to “what is” and “what is not” a project management methodology.
The most popular training and certification program we see today is the ScrumMaster certification. Though we endorse it as a very productive and highly adaptive way to develop software, it has no more to do with project management than choosing to use the Waterfall or for Dummies approach to software development. All three “approaches” can be planned and executed by a Project Manager utilizing an effective project management methodology.
Asking a Project Manager to obtain his ScrumMaster certification is like asking a developer to obtain his scuba certification or pilot’s license. Though both would be great to have, neither is necessary to expertly perform their development duties.
Another very popular certification is the Six Sigma Black Belt. Again, Six Sigma is a very effective business management strategy for quality assurance and constant improvement, but it is not a project management methodology. As with the iterative approach to software development, the Six Sigma paradigms can be employed as project requirements when defining a project, but like most project requirements they have nothing to do with project management.
ITIL, an acronym that stands for “Information Technology Infrastructure Library,” is a set of concepts and practices for managing information technology services, development, and operations but not for managing IT projects.
Now that Webster, Wiki, and I have set the record straight, I would like to offer a few points to consider when evaluating how to invest your project management training dollars. Though it is easy to get caught up in the “latest and greatest,” a little internet research goes a long way. A good project management training and certification program will focus on leadership, relationship building, and executive communication as the foundational skills necessary to lead projects successfully as well as on planning and measuring project progress to control project costs and schedules.
Project Managers are leaders and should focus their training on learning how to leverage the subject matter expertise of their project teams. Accordingly, training or certification programs that focus on specific IT or business subject matter should be avoided. Lastly, project management software is only effective in the hands of a trained Project Manager. Providing training in the use of a Project Management software tool to an individual who doesn’t have a solid foundation in project management techniques will not improve his ability to plan and deliver a project.
If you care to share your perspectives on this topic with me – or if you have a different point of view – please contact me directly as I would love to discuss the topic with you further.