A non-evasive approach to implementing project management processes in an organization or "they never knew what hit them!"
the business case for implementation of project management initiatives
As project managers, we are very much aware of the virtues of managing projects using “generally accepted” (PMBOK® Guide, 2000, p. 3) knowledge and practices. But how do we convince others of those same merits? How do we prove that a scope of work, a WBS, a risk analysis plan, change control documents, a communication plan, etc. make up a “real” project plan? How do we convince those same individuals that a project plan is much more than a Gantt chart?
Over the years of managing projects, I have seen many that were doomed from the start and others that finished either too late or too out of scope to be of any value. Pockets of success were seen but they were few and far between. It wasn't until the late 1990s, with a formal project management process being applied to the Y2K project, did I make the realization that there was a way to manage projects that, though didn't guarantee success, did guarantee that projects would be in control and accountable.
This paper examines how, using the Y2K project as a springboard, project management processes and disciplines were implemented in a manufacturing facility. The paper and subsequent presentation will have the audience retrace the steps that were taken to move an organization from little or no project management expertise and understanding, to an organization that understood, valued, supported, and now requires projects to be managed using “generally accepted” (PMBOK® Guide, 2000, p. 3) knowledge and practices.
Selling Project Management, Non-evasively
Using a “non-evasive” or “soft-sell” approach, two IT projects were selected to demonstrate the effectiveness of applying a project management methodology. In the first, a mainframe inventory application was being targeted for replacement with a windows-based, user-friendly desktop application. The project team was made up of inventory clerks, representatives from Manufacturing, Engineering, and IT departments. A formal meeting was conducted to identify risks associated by doing this project. Since the team did not understand the purpose of a “risk identification” meeting, an explanation of this new project management concept was needed. From this meeting it was determined that the project should not be undertaken because the real problem that the facility was having was not with outdated, cumbersome software but rather, having inventory located in nine separate locations.
Successful Projects Through Cancellation
At first glance one might say, “What a dismal beginning, having to cancel the first project you try using a formal project management process.” In retrospect, it may have been the best way to begin. For by canceling the project before it entered detail planning and execution stages, the management team saw that a successful project is also one that is successfully canceled. Without conducting a risk meeting, the true business need would not have been identified and $70,000 would have been spent on a computer application that still did not solve the business problem.
This first project demonstrated to the organization quantifiable reasons for doing a high-level risk assessment before going too far down the planning and execution trail. It's important to take advantage of every success whether it comes about from a positive or negative experience. This project cancellation was used to “sell” or boast about what might have happened had a risk assessment not been done and further explain other pieces of project management to managers that now had their interest peeked.
Seeing firsthand the value of conducting a risk assessment, this diverse group took their experience back with them into their respective areas and soon realized that if a risk assessment could work with an IT project, then it might also work in other areas.
The second project involved implementing a data collection system on a manufacturing assembly line. Once again a cross-section group of individuals from many departments along with an external consultant formed a team who were led through detailed planning sessions. This team developed, to name a few, a WBS, WBS dictionary, scope statement, network diagram, communication plan, and resource requirements. By explaining each project management activity and why it was being done, the team became active participants and unconsciously began embracing the project management process.
WBS Is Not a New TV Station
As each step of the planning process began, the team was explained the reason why a certain activity was being undertaken. This was done so that they clearly understood what was expected of them so that maximum participation could be achieved. A WBS was clearly a task that the team had never been exposed to and perhaps initially questioned its value. With the first level of the WBS done for them, the project manager facilitated the creation of subsequent levels. As the WBS slowly began evolving, it became apparent that the team began to feed on one another's ideas. As tasks were being listed additional tasks that needed to be accomplished were remembered and listed. The team also came together as a whole as they better understood the entire project. They began to appreciate each other's responsibilities and begin to understand the value of creating a work breakdown structure as a group. Post-It Notes™ were used to create the WBS with the team.
At a follow-up meeting, the team was led through the process of creating a network diagram. By now, the team was anticipating what new “tools” they might be learning to help them plan and execute the project. Creating the network diagram as a group activity gave the team the opportunity to again grow dynamically. More importantly, the team decided the sequence the tasks should be executed. The final team activity was producing estimates on the amount of time required for each task. PERT estimating was used with the group to arrive at the estimates.
Even though this group had no previous experience creating a WBS, network diagram, or using PERT estimation, it was surprising how quickly and energetically they caught on and completed the tasks. Taking the time to explain the process and why it was being done significantly contributed to this success.
Getting External Consultants Into the Act
The importance of explaining each step in the project management process cannot be overemphasized. Not only should the task be explained but also why the task is being done and the purpose it will serve in managing the project. The more failures an organization has had with past projects, the more receptive they may be in trying something new and different.
Involving the external consultant as a member of the team proved to be beneficial. Confusion and assumptions that we saw exist in other external consultant assisted projects were reduced by having them part of the project team. The consultant was able to help plan the project, arrive at the tasks needed, dates when tasks were needed to complete and provide task estimation times. Conducting a final walk through with the consultant eliminated misunderstandings that might have gone undetected.
All Aboard the Project Management Express Train
It was after these two projects that the IT department took on the look of a “virtual” project management office. IT was asked to sit in on meetings and help facilitate projects in the organization. What things can project management do beyond risk analysis? What makes up a good project plan? These and other questions were frequently being asked to the IT/PM office.
Although it was never the intention to convert the facility to project management, what started as an IT initiative to use project management principles soon “snow balled” into many concurrent projects being lead by project team leaders that either sat in on the two original IT projects or received training by the IT department on the basics of project management.
Process Change Projects
The first two non-IT projects that assistance and mentoring were requested for were projects that involved a change in business processes, namely, how employees receive recognition and secondly, how employees are selected for promotion opportunities. In both projects the end deliverable was not a piece of software, hardware, or a tangible product but rather a document that would be used to guide the organization through their treatment of employees.
In both cases the projects had already begun and the “virtual” project management office was called in after two or three meetings when the project teams began drifting aimlessly. It is significantly more difficult to lead and mentor a project team after the team has formed. Whenever possible, a project manager should be assigned at the start of the project and remain on the project until the project concludes.
Although both teams were taught the value and reason behind a project charter, both struggled with the task. The mentorship that was provided involved facilitating the group discussion, helping them reach decisions and keeping them on track in developing the charter. Both groups treated the task as if they were creating a complex corporate mission statement rather than a document that would guide them through the process of creating the subsequent scope statement.
Creating the statement of work was a simpler task for the teams because much of the effort had already been spent developing the project charter and, secondly, they were continually being reminded that they would be allowed to do only what was documented in the scope statement; nothing more and nothing less. In subsequent meetings the scope statement would frequently be referenced to resolve disputes or interpretations on what was in the project.
Mentoring a project that produced an intangible deliverable was much more difficult for the team to relate to as opposed to a project that resulted in a product that could be seen or touched. Due to a perceived sense of urgency, the team did not complete a WBS. So, though planning was done, it was not done to a level of detail that would have improved project success and execution.
During the lessons learned session, the following items were captured: (1) In future projects a WBS should always be completed with the team. (2) A project manager (mentor) should be involved from day one. (3) The project team leaders should not try to do the whole project by themselves.
Divide and Conquer
As more and more projects began, the IT resources became more and more stretched. It was also noticed that more and more individuals were being asked to lead projects without any formal project management training, thus becoming “accidental project managers” (Englund & Graham, 1998). Therefore it was decided to put together a two day project management class which would arm these individuals with enough information where they could get started leading their project and then use the IT/PM resources to assist in mentoring them over the more confusing steps.
Class size was limited to 10 and each participant was required to come to class with a project already assigned to them or a project they recently started. Each participant explained his or her project at the start of the first class session. The class selected one of the projects that would then be used during class as a real-life example to help explain each step in the project management process. Feedback from the classes confirmed that using a real-life project instead of a make-believe project made the class more relevant. It did however, at times, make explaining parts of project management much more difficult. For example, the WBS sometimes could only be partially completed and a network diagram often grew complex and difficult for the participants to follow.
Over a six-month time period, 60 employees were trained in project management basics. Many of these participants immediately put what they learned into use in their role as project team leaders. Others were team members who could now be more productive in their role. Having trained additional employees and setting them off to lead their projects, freed up much needed time to spend on projects needing more technical guidance or projects that directly were connected with other projects.
Although all the classes had very positive feedback, the main criticism was that there was too much new material to absorb in two days. The class centered on teaching the five PMBOK® processes of initiation, planning, execution, control, and closeout. Half of the class time was spent on the planning phase. In retrospect, this may not have been the best method to use especially with individuals who have had no previous project management training. A longer class with even more emphasis on individual projects would have been more beneficial.
Portfolio Management to Emphasize Resource Utilization
With the growing number of projects being contemplated, we were very much aware of a growing problem that not all projects could be worked on at the same time and somehow those that were worked on needed to clearly have their resource requirements identified.
With that in mind we set out to capture all known projects, both active and dormant. Management reviewed the list and settled in on projects with the most important returns would be the ones initiated. Those active projects were then closely scrutinized to ensure all resources needed were identified and times needed were also identified.
Becoming involved with a portfolio of projects was a mixed blessing. On one hand, interest in project management grew so well that management realized the importance of identifying all projects and setting their sites on those projects that paralleled the business strategies. But on the other hand, it now pointed to an area that more time would have to be devoted in identifying, justifying, and prioritizing projects. Additionally, we felt to do project management correctly we needed to begin developing standards and templates that all projects could follow in order to avoid duplicate effort.
With Knowledge Comes Creditability and With Creditability, Acceptance
Although our creditability never came under question, it was good to point to our Project Management Professional (PMP®) certification. We often found ourselves quoting and referencing the PMBOK® Guide as we taught our classes, mentored the project team leads, and discussed projects with the management team. PMP® certification gave us the foundation and reference points needed to lead projects and mentor team leads.
Without the certification and the rigors it took to pass the exam, we believe the knowledge gained would have been absent. PMP certification should be a goal for anyone attempting to implement project management processes not so much for the certification but more so for the useful knowledge that one must obtain to pass the exam.
Simplest Things Can Ensure Project Success
Managing resources correctly can sometimes spell project success. Most projects were being executed on a part time basis by a single resource. In one specific instance, a Human Resource-related project had limited resources yet needed to meet a specific deadline date. During risk assessment, the most significant risk identified was being pulled off the project and put back on doing day-to-day tasks. As a risk response, it was agreed that the resource would dedicate a certain amount of time to the project each week and during that time all disruptions and requests would need to wait.
The department owning the resource and the project manager reached agreement. During the eight-week execution phase of the project a few instances occurred when this agreement came into play. Successfully following the risk plan gave us the opportunity for the project to stay on schedule and for us to emphasize, “boast” if you will, why this project not only completed on time but also finished two weeks early.
The Project Manager As “Numero Uno”
On one project, it was observed that the project manager thought it was necessary to not only manage the project but to also be the main participant in doing the project tasks. To correct this problem, as we mentored the project, push back was continually given to the project manager to delegate tasks and to let the team take ownership of all the tasks. This approach was very effective as it brought the team together and delegated responsibilities to individuals not normally entrusted with task ownership. The project manager became appreciative of the contributions the team was making and relieved that she could now focus exclusively on managing the project.
On another project, the project manager was also the project sponsor. A project manager doubling as the project sponsor is a situation to be avoided. Project scope went out of control as the sponsor continually changed the goal of the project. Change control also went out of control since the sponsor could change anything and was not being held accountable to anyone else. The simplest things can lead down the path to project failure.
Leading Upper-Management Projects
Seeing something firsthand or better yet, trying something first hand can be a powerful deciding factor on choosing to buy into something. Much like test-driving a car, the final sale often will come after you've driven the car. Deciding on a new home computer or big screen TV is often done after trying it out or viewing it. So as chance would have it, an opportunity existed to up-right a project that had gotten mired in execution with the project sponsors being two key decision-making executives.
This project involved migrating internal processes to an outsourcing firm. To reenergize the project, a project-planning meeting was held with the consultants and the key team members. During the meeting the external consultants were introduced and brought on board with the project management processes that would be used to manage the project. Next the project charter and statement of work were reviewed for clarity and understanding. A WBS was then created with the team. It was during the WBS creation that problems that had occurred in the previous months began surfacing. The team began to understand that it was no wonder the project had run aground.
After the WBS was finalized, a risk analysis was performed on all the identified tasks making up the project. This proved to be very beneficial as it again pointed out problems that might occur and in fact already had occur on various tasks. The group came up with risk responses to each risk event helping to put confidence back into the project.
Besides the fact that this project was put back on track through this planning meeting, a significant side benefit that occurred was that two key management decision-makers were able to participate and see first hand the value project management had brought to their own project.
Doing a WBS and a risk analysis at the same meeting was very taxing and sapped the energy level of the group. Though it was accomplished, the recommendation is for a meeting such as this, that it be broken into distinct phases and have a significant break between phases. Ideally one would want to spread this over multiple days if at all possible.
Projects That Don't “Keep Their Hands to Themselves”
While a WBS was being created for a fairly extensive manufacturing production line change project, discussion took place that pointed out the need for some additional departments to become involved. These departments had projects that needed to complete prior to execution of the manufacturing project.
Had a WBS not taken place, as would had been the case in the past, the need for other projects to complete first would not have been identified. This success presented another opportunity to “boast and promote” project management. Following a project management discipline ensured past problems would not be repeated and highlighted the fact that departmental projects often connect with projects in other departments. The success of this project helped us to increase our creditability and gave us an opportunity to get involved in additional departmental projects, thus spreading the project management story.
Managing the Process Compared to Managing the Project
Some of the projects assigned to us for mentoring came with a substantial amount of project planning already done. These same projects often came from guidelines set by an outside consulting firm or from corporate offices. Many of these projects were centered on reducing process variability, six-sigma processes, and continuous improvement initiatives.
In these cases we supplemented the detail project plans with additional project management parts that were found to be missing. Generally we found that a risk analysis and communication plans were most often overlooked. A project charter and scope statement, on the other hand, seemed to be always in good order. WBSs and network diagrams though missing in the truest sense of the word, were present but in a different form. Timing estimates on tasks and resource requirements were present but skimmed over. For example, time estimates were based on single estimates as opposed to PERT calculations. Resource needs were brushed over with a job title or a skill set identified but not with the actual name of the resource that would be doing the work.
In essence we found these projects had the detail necessary to execute the project but not the detail to manage the project.
Taking That Next Step, Creating a Project Management Office
As time went on, it became very evident that the project management process had taken a strong hold in the organization. It was being accepted, used, and everyone was talking the project management lingo. It was then that the resource that was already spending more than fifty percent of his time on mentoring and teaching project management concepts be relieved of his IT responsibilities and charged with overseeing and guiding projects. So by shifting the remaining IT work responsibilities around, we were able to staff our fledgling PMO with one full-time person without adding to the payroll.
Enterprise Projects Implemented Locally
Different problems and challenges came about as we began implementing projects that were deemed enterprisewide, where the end product would be installed in multiple facilities. Among the most significant of these problems were differences on how projects were planned. The amount of detail planning information that was handed to us was far less than what we were accustomed to. These projects had major milestones identified but not necessarily the detail on how to achieve the milestones.
Going about trying to add a second level of detail planning to the master project plan frequently revealed that meeting the major milestones would be in jeopardy. Without the authority to change the master project plan's deliverable dates, we relied on trying to influence the project leaders to change milestones. It soon became obvious that not all project plans are created equal and that there was no formal agreement on what constituted a project plan.
Managing the triple constraints was a daunting task for these lengthy projects. The project needed to always hit its due dates and always remain within budget. To that end, scope and quality were continuously reduced until time and cost could be achieved.
Enterprise projects are a subject all to its self and beyond the scope of this paper but I do offer the following suggestion. Whereas in a stand-alone facility a project manager may have the authority to determine key requirements needed in a project plan and to be personally accountable for managing the triple constraints, that authority may not exist with an enterprise project. Under the directive management model (Martin & Tate, 2001) the enterprise project manager in all likely-hood will hand down project directives but this is not to say that a facility should become a puppet on a string. For what a facility project manager may not realize, is that “we can get things done using influence” (Martin & Tate, 2001, p. 499). Influencing a project can range from clearly communicating how facilities may have different needs and expectations, to influencing decision-makers as they determine how to manage the triple constraints.
When initiating a new program in an organization, a concern that often arises is whether the program will, over time, become the “flavor of the month.” For that specific reason, it was felt not to begin project management with a lot of fan fare but rather take a laid back approach and let the process prove itself. However it was equally important not to be so laid back that no one recognized the value or successes. Therefore, it is important to publicize each success especially to those that can influence the organization the most.
In conclusion, preaching and dictating project management methodologies often times will not be effective in a facility unfamiliar or skeptical of project management. However, demonstrating how project management improves project control, teaching the project management process, allowing persons to practice the concepts, and being available with guidance and answers has proven to be a surprisingly effective technique to ease an organization into a project management culture.
Project Management Institute. 2000. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – 2000 Edition. Newtown Square, PA: Project Management Institute.
Englund, Randall, & Graham, Robert. 1998. Creating the Environment for Successful Project Management. SanFranciso: Jossey-Bass.
Martin, Paula, & Tate, Karen. 2001. “Participative Management: Getting the Most From Your Team.” In Project Management for Business Professionals: A Comprehensive Guide, Joan Knutson, editor. New York: John Wiley & Sons.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA
What’s your PMTQ? Our Pulse of the Profession® research shows that organizations that combine technical skills with project management approaches drive more successful outcomes.