If this book has caught your eye, you are most likely a functional manager working on a project that is not going well. Or, you face an upcoming project that must go well to prevent a serious negative impact on your professional life. If so, you have the right book.
Little attention is given to improving functional managers’ project management skill sets. Why? For one, many functional managers do not even recognize that a project management discipline exists. But best practices in project management, backed by research, have evolved over the past 40 years. These best practices encompass large and small projects in technology, construction, business process improvement initiatives, and more.
Another obstacle is that many functional managers reject project management methodologies, processes, and terminology because project teams either consistently miss their deliverable dates or overrun their budgets. This leads functional managers to underestimate the value of project management in general and feeds attitudes of “project management is a waste of time,” or “project management slows down the process,” or “project management is just a bunch of bureaucratic silliness.” Such attitudes create a formidable barrier between project teams and their business units.
In many organizations, project management’s focus is on controlling and reducing the money wasted on projects. Management implements project management offices (PMO), methodologies, and processes that require excessive documentation, reviews, and bureaucracy. Career paths are built for project managers who learn the science of project management but often lack skill in the art of project management. Little attention is given to how business area and project resources should be aligned to optimize team performance.
Despite these obstacles, functional managers must play an instrumental role in transforming an organization’s approach to be more customer centric, thus helping stakeholders achieve their desired results. This begins with creating an integrated project organization, the heart of which is a partnership between the functional manager and the project manager.
You run a department or division, deal with personnel situations, and resolve day-to-day operational issues. At the same time, you participate in one or more projects. Your participation is necessary—you are an integral part of the project organization. Although your involvement in some projects may be minor, chances are that you are a key player in at least one of them. Balancing the many demands of your functional responsibilities and then adding project responsibilities can be overwhelming and, at times, seem impossible.
In traditional project management literature, a functional manager is anyone with management authority over an organizational unit—such as a department—within a business, company, or other organization. Functional managers are not necessarily affiliated with a project team, nor are they directly involved in the day-to-day management of the project. However, they are supposed to ensure that the team’s goals and objectives are aligned with the organization’s overall strategy and vision. And the functional manager is responsible for providing the project team with the resources needed to complete the project.
Traditional role definitions break down in real-life projects. Project sponsors are often removed from realities of implementation and become distracted by other priorities. Functional managers become more than just resource providers—they become a source of truth for requirements, of validation of a project team’s business process analysis, and of authority in measuring benefits. In reality, functional managers are not only stakeholders but customers of the project team and critical linchpins to project success.
Project teams often have problems integrating into matrix organizations. Overburdened teams become disconnected from the real project need when they lack an understanding of the customer’s business and work remotely from users. They use vernacular in meetings and documents that customers and users do not understand. Furthermore, maturing project management offices (PMOs) stake out organizational authority on how projects should be done. In today’s PMO-centric environment, project teams have little incentive to step out of their comfort zone and truly partner with their customer. Their management structure preaches adherence to budget, resource management, timelines, and following the PMO process.
In my first book, The Strategic Project Leader (Auerbach Publications, 2007), I promote the concept of a project manager becoming a project leader, partnering with functional managers and helping them drive strategic change. I continue to believe this is critical to project success. However, project managers today are still being commoditized and rarely have incentives to step out of their comfort zones. They are unlikely to take the personal risks necessary to see that a project performs effectively. It may get done, but the project will likely underperform, be late, miss critical functionality, and/or run over budget. This is due mainly to the failure of project managers to deal properly with project obstacles that were within their influence. Project teams and project managers often neglect to take a service-oriented view of their role. They fail to understand that they are the spearhead of change in their organization—change through projects initiated to meet the pressing demands of the organization.
Enter the functional organization, your department or division. As the manager, you are responsible for taking delivery of the project team’s output and using it to produce the benefits your executives envisioned. Burdened with the daily meetings and conference calls regarding your regular job, you now have an entirely new organization to deal with: the PMO, the project team, the cross-functional team. Whatever its name, this organization is likely not to be ingrained in your day-to-day work or your span of control. Whether sourced with internal or external resources, this organization is one of outsiders. They report to another command structure, often with different objectives: to get the project completed on time and on budget and then to move on.
Adding to this, you most likely have already seen a project nightmare (or several) unfold before your eyes in your current organization or in a past workplace. And now project charters, schedules, and countless other project templates from this organization are rapidly filling your inbox. You may have a chance to glance at them with limited attention while you’re multitasking on conference call after conference call.
As a consequence, you are not wired into this project organization. You might as well be on Mars, receiving distant radio signals from Project Earth. The result is a gap in provider/customer knowledge, relationship, and unity. I wish all project managers would overcome these obstacles and make it easier for you to connect with the team, but don’t hold your breath. You are the one who must take a step to solve this disunity. And you can. By reading this book, you are already taking an important step toward working more closely with your project team and becoming integrated into the project organization.
One common reason for project failure is the inability of project teams to work closely with the organization or “business” to successfully deliver project results. The functional manager plays a key role in an organization’s ability to structure customer-focused project teams, and this customer focus in turn plays a crucial role in ensuring that the project team understands the business problem or need. The challenge is getting members of the project team to see the big picture and how their work is affecting the organization’s overall long-term goals.
Throughout this book, I use the terms “project organization” and “project team” very carefully. These terms are not interchangeable. Although traditional project management literature uses “project team” to include an array of stakeholders, in this book the two terms are distinct.
A project organization is defined as a temporary organizational structure that is unique to a specific project. This organization includes members of the project team, various key stakeholders, customers, users, advisors, and sponsors.
The project team is a group of individuals who are ultimately responsible for delivering the project deliverables. Those may consist of a new software system; system enhancements; a new product; or a new business process with systems, organizational changes, training, etc. Leading the project team is the project manager.
Standing in the wings is an advisory team composed of individuals who must be consulted to ensure that the change being introduced by the project is acceptable. Members of this team may include regulatory advisors, legal experts, and other functional managers whose processes will be impacted by the project.
Then there is the customer team. This group consists of those individuals responsible for using the project deliverables in a manner consistent with the organization’s business practices to achieve the defined benefits that led to the project being initiated in the first place. This is where many projects fall down. The sponsor is the financial backer and has the organizational authority to get significant resources committed to implementing the change. Too often, we think the sponsor is going to oversee the details associated with achieving the benefits of the project, but he or she is not likely to be involved in the tactical project decisions that will, over the course of months, greatly affect how beneficial the project will be. The critical component of the customer team is the functional manager: someone who will ensure that users comply with new processes, adopt the systems that are delivered, and provide the thought leadership on how this change will impact other aspects of the organization. A functional manager or a group of functional managers is responsible for achieving these benefits.
Functional managers do not simply supply resources to the project. They are a critical component of the project organization, the component that ensures benefits will be achieved. They are co-conspirators in shepherding the needed change within the environment, increasing revenues, reducing costs, improving cycle times, complying with new regulations, and improving customer satisfaction. As a functional manager, you must accept your role as the spearhead of change and work in close partnership with the other spearhead of change, the project manager. This is your call to action.
In order to make this partnership work, the functional manager and project manager must share the same goals, have mutual respect for one another, and have a common understanding of how to achieve the project’s objectives.
The solution is establishing a customer-focused project team that creates an integrated provider/customer relationship. And you must take this step yourself. You cannot rely on your project manager, PMO, or sponsor to integrate this project team into the project organization. They see their roles as something different.
You are probably aware that project managers come in all shapes and sizes. Some are experienced with the organizational dynamics of your organization, while others are oblivious. Having a certified project manager is no guarantee that you have a competent leader.
Project management certifications are similar to technology certifications in that they attempt to measure a project manager’s knowledge, skill, and experience. The most popular industry certification, by sheer numbers that exceed 500,000, is Project Management Institute’s (PMI®) Project Management Professional (PMP®) certification. Among PMPs, the most represented areas of interest for continuing education is information systems.1 This is not surprising, since the project management industry has grown up alongside the information technology industry.
Project management certifications have been beneficial to both practitioners and employers. Many project managers are motivated by the competitive edge offered by certifications, as they can lead to advancement, increased pay, and job security. And trade organizations that support project management certifications have seen continued growth as project management expands.
Don’t be intimidated by these certifications or their holders. Project management certifications use a body of knowledge or framework of knowledge as a basis for the certification. Some certifications focus on knowledge and level of experience, while others include more emphasis on assessments and performance-related criteria. In other words, some certifications focus not just on what a practitioner knows, but how he or she performs. However, the PMP remains a knowledge test even though experience is a qualification to sit for the test. It’s a useful certificate, but no guarantee that you have the project manager your organization needs.
PMOs also come in various shapes and sizes. Some are mature, others weak and very loosely structured. Mature PMOs have management power that can rival functional management powers. These PMOs focus on keeping projects from running out of control, managing budgets, and keeping really bad things from happening. And they often do a good job of keeping projects that should not be initiated from getting approved. They have the power to prevent resources from supporting projects that will not provide value or are simply wish list requests from those adept at using influence to get what they want. However, even mature PMOs may be less concerned than you that the organization actually reaps all the intended benefits.
The project sponsor is the financier and the visionary of the project. A good sponsor initially will sell the vision of the strategic initiative, particularly during its funding. From that point on, however, visions for transformational change are often significantly under-communicated or barely conveyed at all.2 Sponsors are usually very busy people who rely on functional managers to continually communicate the vision during a project’s life cycle. Filling this communication void is a critical role for the functional manager.
Although sponsors drive the early stages of the project, securing funding and defining high-level objectives, they rarely have the time or knowledge to organize project stakeholders into a healthy, high-performing organization. To put it simply, sponsors expect the people under them to have the competence, professionalism, and technical skills to “just get it done.”
I hope you are coming to appreciate your unique role in successful project execution. That is, to facilitate an integrated provider/customer relationship that we can call the project organization.
An integrated provider/customer relationship produces benefits. It is likely to establish trust, help team members work in a more cohesive manner, and, ultimately, increase project performance. But that’s nothing new, is it? Why can’t we get there on our project today? One reason is the need to redefine the role of the functional manager, and then engrain that definition into project organization structures. Before this can happen, all stakeholders must recognize that the functional manager plays a key role in developing this integrated provider/customer team.
The structuring of the project organization must clearly define the role of the functional manager as an educated customer. Whether in IT, marketing, or accounting, whether running a collection department or managing faculty, the functional manager can define what is needed and enhance the project team’s understanding of the business need. The functional manager can recognize a valuable project management process as opposed to non-value-added work. Project team members often lack critical business subject matter expertise. Therefore, the functional manager, like it or not, needs to be the catalyst for transferring this critical knowledge in order to establish a true provider/customer partnership. When functional managers become project management aware, they can better participate in project planning sessions, understand why key planning documents are needed, interpret project reporting artifacts, and recognize when project teams are wasting precious time and resources. The sooner this awareness occurs, the sooner you will see dramatic increases in project performance.
A savvy project manager will validate a functional manager’s competence to participate as a customer, just as a functional manager must validate the project manager’s competence to provide the deliverables that are crucial to meeting executives’ expectations. This productive partnership will benefit us all.
For a provider/customer relationship to succeed in providing great benefit to your organization and your career, it must evolve out of mutual respect and a common understanding. That understanding includes business matter expertise on the part of both provider and customer. This does not mean you should expect a project leader to understand every nuance of your complex operation or be an expert in each aspect of the project. It does mean that the project leader must possess enough knowledge of your business that he or she can articulate it in a manner that quickly enhances credibility. Such business knowledge is essential for developing trust with you and other stakeholders on the customer and advisory team. The project manager’s business matter expertise is not about having the ability to master all aspects of your job; rather, it means understanding your business. As a functional manager, you must be able to assess the project leader’s knowledge of your business and fill any gaps in that knowledge. Be wary of project managers who take what they learned on their last job and apply it blindly to your operation.
In your new project role as a customer, you will place a premium on the leader’s objectivity and recognize and appreciate that person’s expertise in project management and familiarity with your needs. Savvy customers will not waste resources on teaching the strategic leader about the business because your experienced staff can fill in specific knowledge gaps. What you should expect and test early in your project is the project manager’s genuine interest in your business need and his or her ability to quickly gain business matter expertise about your operation, business processes, and key metrics.
Don’t assume that project managers must have many years of experience in the industry to be able to lead a strategic project. On the contrary, such managers often do a poor and ineffective job as project leaders because they are too transaction-focused. They cannot see the overarching processes associated with creating transformational change and they do not know how to create value in team members without years of similar industry experience.
Trust is a two-way street. You must allow the project manager to develop meaningful, trust-based relationships with you and your key stakeholders, including sponsors, influential parties, and users. This trust begins with the project manager’s credibility, which encompasses his or her project management expertise and its applicability to your present situation. Reach out and provide an invitation to your project manager to begin developing these relationships and nurture them during the early days of the project.
Your trust is crucial for the project manager to navigate the political minefields within the project environment. A lack of knowledge of your business is a barrier to that trust. The project manager will be ineffective if he or she cannot understand your business need.
In a strong provider/customer relationship, both parties continually project the vision of the initiative to influential stakeholders, particularly those who are more distant or who possess a distorted view of the initiative. These stakeholders can generate chaos by their complacency, lack of support, or even active resistance. The projection of the vision can only be done effectively if both the provider and customer share a thorough understanding of the situation, and its uniqueness, urgency, and hidden implications to the enterprise organization. Investing in this education and trust-building with your project team has an important and subtle benefit: they will develop a deep knowledge of your situation and become fully engaged in the endeavor, making it difficult to avoid their leadership duties.
Most projects begin with the noble goal of adding value to the organization. Certainly, sponsors still use pet projects to enhance their resumes or exercise a power grab. But as research shows us, unfortunately, many projects are completed with less than the expected benefits.
As a functional manager, now in the role of the customer, you must commit to having measurable benefits, and you are the person in the project organization who is most critical to making this happen. Your project charter may have listed hundreds of thousands of dollars of benefits, but have you really bought into them? So often business analysts—consultants hired by executives—write up these cost/benefit analyses without your buy-in, for the sole purpose of achieving funding. When the time finally comes to execute the project, consulting those documents is rare indeed.
Do yourself and your organization a huge favor: dust off that cost/benefit document at the kick-off meeting and begin planning how these benefits will be achieved and measured in your department or division. The sooner you focus on how to measure the benefits, the greater the probability that your project will add value. Decision making will be more effective in the project planning and execution phases when everyone understands the metrics and how the project deliverables—software, training, infrastructure, marketing collateral—will move these metrics.
Once you accept the project deliverables, the project team typically disengages or begins to shut down the project. But too often, acceptance becomes a wishy-washy informality that allows everyone to declare victory and move on. Your mandate: ensure that you have 100 percent confidence in the deliverables and their ability to provide the intended benefits for your business operation. Insist that project teams submit their deliverables often and early. Prototypes, drafts of design documents, and current and future state process maps are very valuable in achieving value-based project status. Before you sign off, insist that your deliverables are proven to work in normal operations, especially if you are dealing with external vendors and consultants.
I found myself in an uncomfortable situation as a project manager a number of years ago with a customer who was accepting delivery on a large custom software application to automate the loading of data from clinical case forms into a database. It was uncomfortable for me because, while the functional manager knew exactly what was needed to achieve their benefits, I did not. I knew I needed acceptance so my company could get our final lump sum payment. My motivation, certainly emphasized by my bosses: get acceptance and get paid so we can make a profit on this project. You see, in professional services, organizations are often incented to do the wrong thing, namely, to place their motivation and goals over and above the customer’s goals.
As the project began to wind down and we were testing the application in the customer’s test environment, I notified my customer that once all the testing was satisfactorily completed in this test environment, we would expect payment of the final invoice. Tim, my customer, insisted that the project would not be completed until they put the application in production and made sure everything was working properly. Of course, once a disagreement arises over the payment of a $120,000 invoice, the best thing to do is check the contractual language. To the dismay of both parties, the language was vague enough that neither could claim the upper hand. Tim felt that if he accepted this complex piece of custom software too early, and they later found bugs and other unforeseen issues in production, they would then have little leverage to get them resolved.
My problem was that my customer was not planning on putting the software into production for another 60 days, and once it was in production, the number of technical environment variables increased dramatically from the more controlled test environment. We could be wrangling for months about issues over which I and my technical team had little or no control. Project team hours would increase, eating away at our profits and risking an overrun of services against a planned budget. If I did get acceptance in the test environment, the production environment issues would become a maintenance and support issue, one that caused less concern for me and my boss, because it was a totally separate internal organization with different management. At the end of the day, someone was going to take a beating on this contract.
As the project manager, I had not prepared my team or management with the proper plan and estimate to meet the project requirements. Meanwhile, my relationship with Tim was anything but warm: we never really connected and communication was poor. He never seemed to have time for this project; other tasks were always more pressing.
A close provider/customer relationship did not exist in this situation, with plenty of mistakes and missteps on Tim’s part and on mine. However, Tim was the customer. He understood project management but felt project plans were a waste of time. He just wanted it done.
In the end, we negotiated terms so that my company would be paid within 60 days if the software was not deployed in production and would receive most of the payment as long as there were no severe bugs. Neither we nor the customer won or lost; we both survived. A provider/customer partnership must have common goals and a strong level of interdependence to be successful.
Although having trust-based relationships between provider and customer team members is essential, having an organizational structure that supports the execution of projects is also critical. Functional managers must understand the type of organizational structure in which they are operating, its impact on projects, and the implications for the project manager, the project team, and themselves. Three basic structure scenarios exist and I have experienced the challenges associated with each of them.
The functional organization structure aligns around the major functions of the business. I encountered this first scenario when I led a large strategic project for a publishing company early in my project management career. The company had few project management processes and even fewer project managers. I was actually a financial analyst working for the CFO of the organization. The organization was steeped in tradition and had several flagship products that were well known all over the world. Of course, these flagship products had senior vice presidents overseeing them—and attaching their careers, kids’ education, vacation homes, and retirement to the products’ success. In other words, the power associated with these signature products was enormous and these people would and did do practically anything to hold on to that power.
I was assigned to help the comptroller implement a general ledger system, which was to consolidate all of the company’s financial books into one system controlled by the CFO. Prior to this project, the CFO had to rely on the COO to extract financial data from an antiquated, legacy system. This created myriad problems, particularly when ad hoc financial reporting requests came in from the parent company. At such times, the CFO had to beg and plead with the COO to have the programmers write obscure, one-off code to output this data. It was a classic confrontation of functional vice presidents fighting it out every day over their priorities and how to use their resources.
Then I entered the scene, a young financial analyst who barely knew anything about project management, charged with implementing the new system. Thanks to scope creep (see Chapter 3), the general ledger implementation became an Enterprise Resource Planning (ERP) implementation. This system was going to be implemented in the warehouse to manage inventory, in marketing to manage leads, in order processing to handle incoming orders, and, of course, in sales for reporting and projections.
The organizational design of this company was the functional organization structure. Power was embedded into the major functions of the business: operations, which produced the products; publishing, which owned the content; marketing; sales; and, of course, finance. And each had a powerful VP who didn’t want anyone encroaching on their territory. Figure 1-1 is a diagram of a classic functional organization.
In my example of a classic functional organization, although the resulting product did get implemented, different divisions adopted aspects of the system and painful battles broke out almost weekly as functional managers clung to their power and resisted change. Was the project a success? Yes, but many benefits were left on the table due to lack of adoption across the company.
Figure 1-1 Classic Functional Organization Structure
In teaching project management classes, I typically have at least one student in the class who has an “ah-ha” moment, realizing that his or her company is predominantly a functional organization. It can no longer adapt to the changes of its competitors or demands from its customers. Most projects in such a company underachieve their promise by between 20 and 70 percent, and project and functional managers become cynical.
In functionally aligned organizations, functional managers have the responsibility to design and implement technical requirements. Project managers and their teams have limited authority and are often just coordinators and note-takers. Little sharing of project resources or information takes place across departments. Project costs are difficult to track and project communication is hampered. Success of the project is often associated with keeping the project boundaries within the functional manager’s control. The more other departments or organizations get involved in the project, the greater the probability of conflict and poor project performance. In order to succeed in such situations, functional managers need to be well versed in project management processes. However, most functional organizations do not formally recognize project management as a discipline; therefore, processes are often ad hoc and dependent upon the experience of the functional manager.
The functional organization is not necessarily bad; it can be effective when it has only a few high-volume product lines serving a common market, its operations are fairly consistent across products, it has a large customer base with consistent requirements, and its business segment is slow to change.3
At the other end of the spectrum is a projectized organization, one that is primarily aligned around projects or programs. The planning, execution, and control of projects and programs is usually a part of the organization’s core business and revenue often is tied to the successful completion of projects. Project management processes are mature and financial tracking of project expenditures is ingrained into management information systems. With a clear management structure for project managers, career paths exist for these employees. They have significant authority over project budgets and resources and are fully allocated to project work.
I worked in a projectized organization for several years and learned much about project management. My projects left me with a range of experiences—good, bad, and ugly. One of the more positive experiences was working with a customer in a large pharmaceutical organization. John was a 25-year veteran of the organization and had worked in numerous capacities during his career with this company. John had five years until retirement and I got the sense he had won and lost his fair share of battles in the organization. He was the sponsor, customer, end user, and manager of the department that was to use a new system to scan and archive the department’s information and manage it through a workflow process. The goals were simple: improve productivity and reduce cycle time of his department processes in order to improve the speed at which new drugs were approved.
John was a great customer. He taught me a lot about how a customer in the project environment should act. He spent many hours with me going over a vast array of company processes and relationships—how this department works with that department, who is politically important and who isn’t. John never shied away from a difficult discussion; many times he forced them to occur. “Bad news only gets worse if left stagnant,” he would always say. The project requirements, project plan, and communication were solid and we followed them closely. Weekly updates, regular e-mail and conference calls, and several on-site visits kept project information flowing smoothly. John was also very inquisitive. He wanted to understand the plan, understand the logic of why we were doing certain tasks in the development and implementation of his project.
Working in this projectized organization gave me complete control over the project resources and project plan. As the project manager, I was accountable to get this completed and make sure John was happy. I had all the information on budgets and costs at my fingertips and was able to act accordingly to keep the project on schedule and on budget. We had clear policies and procedures on managing projects from initiation to closure. Figure 1-2 shows a hypothetical example of a projectized organization most common in the professional services industry.
Projectized organization structures are certainly helpful for project managers who desire and seek the accountability associated with managing projects. However, they have implications for the functional manager. For one, projectized organizations often are hired by organizations that do not have the project management processes and skills to complete the work themselves. As I described in the story about Tim and the custom software application, projectized organizations can be professional services firms that sometimes have incentives to do the wrong thing and put their priorities above their customers’ priorities. Thus, functional managers commonly find themselves in an immature project management organization that has engaged a mature projectized organization for assistance. In some cases, particularly in large organizations where the organizational structure varies among divisions, the engaged provider is an internal organization with mature project management processes. Whether external or internal, a mismatch of knowledge and expertise is likely in the provider/customer relationship and must be overcome. In my experience with John, I was fortunate to have a customer willing to share his knowledge, identify potholes to avoid, and take a sincere interest in how I was running the project.
Figure 1-2 Organization Structure
Understanding the predominant nature of functional and projectized organization structures provides a backdrop for the most common type of organizational structure and the one in which most of us work, the matrix organization. In its simplest definition, a matrix organization is a grid-like organizational structure that allows a company to address multiple business dimensions using multiple command structures.4 Organizations use matrix type structures to avoid staffing up; they leverage resources across the organization while remaining smaller and task focused. Matrix structures help spur innovation and quick reactions to business environment changes. However, such structures also can become very complex and lead to unpredictable results. Matrix organizations may lack clear authority definition, which can lead to role ambiguity. Some may require significant additional administrative and overhead resources to support the matrix.5
There are various forms of matrix organization: the weak or functional matrix, the strong or projectized matrix, and the balanced matrix. The classic balanced matrix officially designates an employee as a member of two different organizational units. In the weak matrix, employees remain members of their functional units but are loaned to other teams or units on a part-time basis to facilitate project work. In the strong matrix, the employee moves from one organization unit to another to complete initiatives and remains a member of that unit while the work is being completed. Strong matrixes have well-developed project management functions to support project work across the organization. Figure 1-3 depicts the three types of matrix organizational structures and the abilities of their functional manager and project manager to control the project.
The greatest challenge for project workers in matrix organizations is role ambiguity. Particularly in large organizations, roles around projects can become vague and confusing, drive unhealthy conflict, and shut down communication channels. Clearly defining temporary customer, project, and advisory teams and the roles and responsibilities of each team associated with a specific project will benefit the organization.
In matrix organizations, especially weak or functional ones, project management knowledge is generally centered in the information technology functions, rather than in the business units. Such organizations need help in improving their project management capabilities, which requires not just hiring or training better project managers or implementing a binder of forms and templates for each project. Rather, it requires education of the entire organization on how projects should be planned, executed, and controlled, with the customer—the functional manager—being the critical linchpin whose own education provides the impetus for better organizational management of projects.
Figure 1-3 Project Control in Different Types of Matrix Organizations
In a perfect world, every project completed is on time, within budget, and delivers the measurable results and quality customers expected. But in reality, projects underperform or even fail at an alarming rate.
Many drugs come with warning labels: “Do not operate a motor vehicle when taking this medication.” Unlike products, projects do not display warning labels. If any type of warning is given, project team members likely overlook or ignore it, particularly in the early stages of the project. And by the time true warning signs emerge, it is already too late. Your project is likely to underperform. What are the serious warning signs? Your project begins to appear disorganized. Resources are working in silos and no one seems to know what other team members are doing. Team members live by the creed, “It’s not my job,” or “I’ll do my part and after that, it’s their problem.” Finger-pointing ensues.
A common method of project status reporting is the red, amber, or green (RAG) ranking, which is usually very subjective. Most projects start out in a green status, meaning everything is under control and on schedule. The danger of this thinking is that it lulls everyone into a sense of complacency and complicity. Organizational culture makes it difficult to place a project in red, or any status other than green. Such an action would implicate numerous organization representatives, including the sponsor, customer, and project manager, and the PMO processes and their management.
As the customer in a provider/customer relationship working on a high-stakes project, be cautious of an initial project status of green. Once a project is labeled as having a green status, it is unlikely to change even if such a change is warranted. Project and customer teams should have to earn the green status that signifies the project is under control. A green status is meaningless when no real, tangible work has been accomplished yet. Red status is usually reserved for getting management’s attention to something that requires their action. Most often, that is a need for more resources or an alert that certain future events (risks) are highly probable and will greatly impact the achievement of project objectives and benefits to the customer.
When projects begin to show signs of stress and failure, everyone looks to the project manager for answers. It may seem unfair that the burden of doom falls upon a single individual and, in fact, functional managers may directly contribute to project failure without really knowing it. This happens when functional managers do not understand, acknowledge, and embrace their critical role in achieving project success. In a healthy provider/customer relationship, the burden is shared and solutions are worked out as a team. Projects, both simple and complex, underperform or flat out fail for many reasons. These may include poor project management, unclear objectives and goals, lack of organizational support, lack of user input, unrealistic time frames, poorly managed expectations, and unclear roles and responsibilities. Doubtless, project managers, project teams, and executives deserve their share of blame. But what about you? Remember, your primary role in the organization is performing the duties aligned with your function, duties that determine your performance, bonuses, and promotion potential. At a minimum, a project-savvy functional manager—a customer—can contribute to heading off the root causes of project failure. You have a strategic role in your project and that is making this provider/customer relationship work.
Table 1-1 lists common reasons for project failure in the left column.6 For each reason, it provides ways that you can have an impact on these root causes.
Project failure is a huge problem for all organizations. According to the Standish Group, which studies project failure rates every few years, findings are dismal and getting worse again after slight improvements in the project success rates in 2004. In 2009, 32 percent of all projects succeeded, with success defined as delivered on time, on budget, with required features and functions. Forty-four percent were “challenged,” meaning they were late, over budget, and/or delivered less than the required features and functions. Of all projects, 24 percent failed. These were cancelled prior to completion or delivered and never used.7
These numbers represent a downtick in the success rates from the previous study and show a significant increase in the number of failures. Companies are wasting billions of dollars on failed projects. Some calculations estimate the cost of IT project failures at $6.2 trillion per year worldwide, with $1.2 trillion in the United States alone. To put this in perspective, the United States spent $1.5 trillion on bailouts during the 2008–2009 financial crisis.8 The vast majority of this waste is avoidable: simply make sure the right business needs (requirements) are understood early in the process through a strong provider/customer relationship.
Table 1-1 Functional Managers’ Impact on Causes of Project Failure
The economy may be driving some project failures by spreading overworked resources across too many priority projects. However, studies attribute the main causes of failure to lack of execution and focus and an increase in process, tools, and red tape.9 Process isn’t helping; it’s hindering!
Standish research highlights that the current process mindset many organizations have toward project management is a downward spiral: project success rates are low, so we put in more controls. This means less time managing projects and more red tape, which in turn leads to even lower success rates. Often, these processes put a premium on documentation, status reviews, change control, and milestone review. All are driven mainly by PMO management and directed at project managers and their teams. Customers and functional managers see these activities as having low value and being, in fact, the barriers to getting things done quickly. Ultimately, the provider/customer relationship suffers.
If your project management organization appears more concerned about process or methodology, don’t let this fool you about what’s important. Project success is achieved when smart, capable project managers partner with savvy customers and are allowed to focus and spend time on what’s essential to get their projects delivered. You, the functional manager, play a key role in creating the integrated project organization that is necessary to achieve project success.
1. Michael Price, “Learning Preferences and Trends of Project Management Professionals (PMP): A Preliminary Report” (Paper Presentation, Project Management Institute Global Congress Europe, Prague, 2004).
2. John Kotter, Leading Change (Boston: Harvard Business School Press, 1996), 91.
3. Kevin Forsburg, Hal Mooz, and Howard Cotterman, Visualizing Project Management: Models and Frameworks for Mastering Complex Systems (Hoboken, N.J.: Wiley, 2005).
4. Thomas Sy and Laura Sue D’Annunzio, “Challenges and Strategies of Matrix Organizations,” in Human Resource Planning (Alexandria, Va.: Human Resource Planning Society, 2005), 28.
5. Sy and D’Annunzio, “Challenges and Strategies,” 28.
6. Tom Carlos, “Reasons Why Projects Fail,” Project Smart, http://www.projectsmart.co.uk/reasons-why-projects-fail.html (accessed February 22, 2011).
7. http://www.standishgroup.com/newsroom/chaos_2009.php (accessed October 28, 2011).
8. Roger Sessions, “The IT Complexity Crisis: Danger and Opportunity,” Object Watch White Paper, http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf (accessed February 22, 2011), 1–3.
9. Mike Boyer Smith, “Standish Group Chaos Report finds increasing project failure,” The Productivity Habit, http://theproductivityhabit.wordpress.com/2009/05/04/standish-group-chaos-report-finds-increasing-project-failure/ (accessed February 22, 2011).