Gain and maintain authority to ensure project success



Gain and maintain authority to ensure project success

by  Jason P. Charvat  |  More from Jason P. Charvat  |  Published: 11/20/02

[pic]

[pic]

Rating:  3.3 (out of 5) | Rate this article | Send us feedback | |

|[pic][pic]Hide |

| |

| |

|Hide |

| |

|When your project fails, there is only one person your boss will look to for an explanation: you. As a project manager, you will be |

|held accountable for the overall success or failure of a project, even if the reasons for the project failure were out of your |

|control. As such, PMs must ensure they have the authority to see the project through. There are three key elements that form the |

|backbone for achieving any success in project management. They are: |

|Authority: The legitimate power given to a person in an organization to use resources to reach an objective and to exercise |

|discipline. |

|Accountability: Being answerable to one's superior in an organization for the exercise of one's authority and the performance of |

|one's duties. |

|Responsibility: The duties, assignments, and accountability for results associated with a designated position in the organization. |

| |

|Organizations should inform project managers about the authority they will be given for each project they manage. All too often, |

|organizations ignore this responsibility and problems such as conflict, confusion, and communication breakdowns start occurring. As |

|project manager, you will be held accountable for the project. Your first objective should be to assess whether you have the |

|authority you need to get the job done. Typically, projects cross multiple departments and it’s not always clear who holds the |

|authority for many decisions. This uncertainty leads to political maneuvering and may also block project progress. For example, how |

|can you be held accountable for a project’s success within a matrix organization when you don’t have any management responsibility |

|over the resources within the functional departments (e.g., UNIX, NT, SAN, Ops, DBAs, etc.). You may be new to the company, making |

|it even more difficult to negotiate in obtaining the types and quantities of resources you need. This ultimately delays your |

|schedule and, therefore, your project performance. Figure A lists the types of responsibility/accountability challenges faced by |

|many project managers. |

|Figure A |

|Daily challenges many project managers face in the pursuit of being accountable |

| |

|Description |

|Resolve by |

| |

|Organizational structure hampers getting correct resources |

|Negotiating upfront with functional managers |

| |

|Not given the responsibility to succeed |

|Obtaining executive buy-in and sponsorship |

| |

|Insufficient priorities allocated to your project |

|Escalate and reprioritize your project to the appropriate level |

| |

|Stakeholders unsure of their purpose on the project |

|Create a roles and responsibility document and review with all stakeholders |

| |

|Issues drag out and aren't resolved |

|Need executive buy-in and sponsorship |

| |

| |

| |

| |

|Demystifying roles and responsibilities |

|Although the role of a project manager may vary by the size and complexity of your IT project, you may need to take the role of: |

|The client/customer interface |

|The project leader and integrator |

|The project resource manager |

|The delivery manager |

|The acceptor of project deliverables |

| |

|The following core responsibilities form the backbone for your project: |

|Selecting the core team with the project sponsor and functional managers |

|Identifying and managing the project stakeholders |

|Defining the project |

|Planning the project |

|Identifying and managing issues and risks |

|Allocating and securing resource commitments |

|Monitoring and tracking project progress |

|Solving the problems that interfere with progress |

|Controlling cost and schedule |

|Leading the project team |

|Communicating progress status |

|Delivering the project deliverables and benefits |

|Managing the performance of everyone involved with the project |

| |

|It’s equally important to make the distinction early on in the project regarding authority and responsibility. The way that this can|

|be achieved is for project managers to clearly define the project responsibilities of stakeholders on the project through the |

|project brief, management plan, and definition report. |

| |

You can also include these documents in a roles and responsibility matrix. Any one of these documents will assist you in clearly setting the individual expectations on the project. Figure B shows a typical Roles and Responsibility matrix chart to clarify the various responsibilities. For example, WBS item 1.2.4.1 shows that the project manager is responsible for performing the cost estimation. If this were not done, then the project manager—and no one else—would be held accountable.

|Figure B |

|[pic] |

How to achieve authority and success

If you are not given the authority to manage project resources, then you need to arrange a meeting with those stakeholders who do have the authority to "make things happen." One secret to help hold people accountable for project tasks is to ensure that they clearly understand that you will be providing feedback into their yearly performance reviews. Once project members understand they are being held accountable, you’ll have to ensure that your team members will be able to complete these responsibilities. Here are some techniques you should use to enable a project’s success:

• Provide leadership and interpersonal skills: On any project, it’s people and not plans that make successful projects. It’s crucial that project managers are responsible for providing the leadership and effective interpersonal skills between all project stakeholders.

• Provide good communication: Clearly effective project communication is critical for relaying expectations and feedback among stakeholders throughout the entire project life cycle.

• Manage the entire project plan: Project managers must track and monitor the overall project schedule as planned. Daily issues and risks should be documented and resolved expeditiously. Don’t think of quick wins and manage the plan only once in a while. That won’t work. Instead, manage on a daily basis and your job will be more rewarding.

• Assess project performance: As project manager, you should be able to identify and collect daily assessments and metrics of your project performance on a regular basis. This should allow you to measure whether you are ahead or on track with the planned schedule, budget, and specification. Any indication of a deviation for each deliverable must be immediately corrected.

• Manage project scope: Ensure that you are able to track and manage all changes on the project, in order to deliver what was originally scoped out in the first place.

The most successful project managers are those that are also willing to work with executives in order to get this authority. If you haven’t been given the authority to make large equipment purchases or hire IT staff, which are vital to a project’s success, then you could very well land in trouble and even lose your job. Don’t just assume you can take the authority—you have to ask for it. In this way, you are most certain that executives will be aware of the level of authority you are exercising on your project.

Exceeding your project management authority can be very easy if you are not provided with a clear “delegation of duties” from your project sponsor. This should clearly describe exactly what authority you’d have as a project manager. I recall a recent case where a project manager was hired to take charge of a SAP R3 implementation. The timeline to get a development environment established was extremely aggressive. The first problem he encountered was that the company executives kind of sat on things for a while, before approving anything. The vendor was anxious to deliver and meet the project timeline, but the quotes were caught up in the company approval process. Being impatient, the project manager proceeded to issue the vendor a letter of intent by himself, hoping this would reduce the lead-time on the delivery of the equipment—not anticipating problems, as the company would pay sooner or later. Sadly, the company’s financial executive discovered a letter of intent was issued and the project manager was subsequently fired. His response was that he assumed he had the necessary authority to get his project completed on time.

Mission accomplished!

The old axiom, “The buck stops here,” applies to both executives and corporations trying to hold project managers accountable for a project’s success. Companies need to allow project managers a far wider range of authority if they are to successfully manage their projects. Far too many “old-world” organizational structures stifle today’s way of doing business. If project managers are empowered, they’ll happily accept being held accountable. If project managers are left negotiating for resources all the time, then get ready for more failures and finger pointing.

Project managers will not accept accountability for the result of their actions if they are managed in an authoritarian way. If company executives want improved project delivery results, the only way to achieve this is to provide project managers the authority they need and hold them accountable for the results.

Examples of Authority To Ask For:

|Assign Tasks and Timeframes (How, specifically, will the tasks differ if more than one manger|

|can assign tasks?) |

|Select Suppliers |

|De-select Suppliers |

|Select Staff |

|De-select Staff |

|Influence Supplier Payments |

|Influence Staff Remuneration (How, specifically?) |

|Set Context for the Work |

|Set Boundaries for the Work |

|Veto Approaches |

|Make Make/Buy Decisions |

|Budget |

The Hampton Group, Inc. 5031 S. Ulster Street, Suite 240, Denver, CO 80237-4320 USA

© 2004 The Hampton Group, Inc. All Rights Reserved. May not be reproduced without written permission . The Microsoft Corporation owns the registered trademark Microsoft Project®. The Project Management Institute, Inc. owns the following registered trade and certification marks: PMI® PMBOK® PMP® and CAPM™. The CompTIA IT Project + certified professional logo is a registered trademark of CompTIA (the Computing Technology Industry Association). All rights reserved.2003

[pic][pic]

|The Four Seasons of Project Management (Part 1) |[pic] |

|Sainath Nagarajan | |

|March 2, 2005 |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| | |

| |[pic] |

| |[pic] |

| |Project Management |

| |Leadership/Soft Skills |

| |Advice, Anecdotes and Case |

| |Studies |

| |[pic] |

| | |

| |[pic] |

| | |

| | |

| |[pic] |

| | |

| |[pic] |

| | |

The classical definition of project management and approaches to project management suggest a detail-oriented, process-centric approach to the profession. I would submit however, that all project managers are not created equal. I've observed four distinct governing characteristics in project managers:

|[pic] |

|[pic][pic] |

• The Planner: Focuses on the process of managing a project

• The Expeditor/Coordinator: Focuses on maintaining the pace of project information flows

• The Analyst: Focuses on the product being delivered

• The Leader/Manager: Focuses on the people involved in a project

The Planner: Focus on the Process

This project manager, follows a classical engineering approach to the profession, and would be found drawing up detailed project plans, defining work calendars, activity codes, assigning activity codes and resource allocations at the minutiae, using earned value management for risk assessment and control, and managing to pre-planned and almost-scripted routines. There is an air of "Roberts Rules of Order" in this PM's meetings, and almost predictable routine to how information flows within project teams. There is a focus on directly managing specific tasks, and supporting activities to the tasks.

 

This management style is rooted in formal engineering practices, with a focus on data and process. This style is usually best suited to engineering, environmental, construction, utilities and telecommunications industries, where control of large complex tasks is required, with precision hand-offs and schedules.

 

While this project manager is definitely an asset to ensure control and governance, they tend to be viewed as bureaucratic or too process-centric. This PM might expect team members to provide inputs at the most granular level of detail, which might result in being inundated with too much data.

 

The risk with over-information is that a bottom-up view of the project might tend to cloud the overall strategy and vision of the business. This PM might expect all stakeholders to have a consistent understanding of and adherence to the established project management and delivery processes.

 

The Planner PM needs to focus on customer needs, and be able to effectively espouse the interests of a process-centric approach without showcasing the process itself. The Planners need to be cognizant that change happens, and be ready to accommodate to change without putting up process barriers. They also need to be sensitive to the needs of stakeholders that are not used to the level of detail that they are, more so when dealing with executive management. Business sponsors need results, not the process.

 

The Expeditor/Coordinator: Focus on Pace

This project manager is essentially the hub in a hub-and-spoke team structure, working like a traffic cop by moving information across team members, ensuring that the pace of work is constantly maintained. There is a lesser level of direct involvement in understanding the details or working out detailed plans, and the focus is largely on pace. Resource/schedule allocation and updates, risk assessments and formal project updates are less frequent. There is an air of "continuous movement" in this PM's style, with very frequent (even granular) task assignments, follow-ups and reassignments.

 

This management style definition is distinct from the project expeditor and project coordinator organization roles. The classical project expeditor organization role is rooted in little formal authority, while the project coordinator role has more staff authority. An Expeditor/Coordinator PM exhibits a management style that combines elements of the above organization roles.

 

This style is usually best suited to projects within a functional domain, where the PM has line authority and staff authority over the resources assigned to the project. In a multi-domain, cross-functional project, this style of project management could be perceived as lacking in formal authority and accountability.

 

While this project manager is an asset to ensure pace, continuity and communication between stakeholders, they tend to be viewed as rather distant and more focused on the tasks than the people. The constant management at the task level could tend to be viewed as micro-managing, and this could be concern when dealing with knowledge workers who might prefer more self-management. The Expeditors/Coordinators need to focus on people needs, and manage the risk of being perceived as ring masters.

 

In the context of a WBS--probably the most commonly used PM artifact--Jim Harris (in his gantthead article "Death by Data Suffocation") has succinctly stated that the words "work breakdown structure" are "not a title, but a stated purpose."

 

Project managers need to manage with the right level of detail needed to get the work done, yet not get bogged down in the tar pit of tactical plans. The objective of project management is to enable actionable business results, and not merely to establish governing practices at the risk of neglecting the purpose.

 

In the second part of this series, we will look at two other styles of project management; one that is rooted in the world of business/systems analysis and the other in the domain of leadership.

 

Sainath Nagarajan has project management and business analysis responsibilities at the corporate offices of a global, publicly traded business services company. He is a graduate of the Master of Information Systems Management (MISM) program at Carnegie Mellon University, holds a Masters degree in Financial Management and has read at the Programs on Negotiation at Harvard Law School. The views expressed here are his personal views. As always, they seek to inspire constructive discussion, debate and dialog. He would like you to contribute your experiential insights, to further the profession. Comments are welcome at sai@.

|The Four Seasons of Project Management (Part 2) |[pic] |

|Sainath Nagarajan | |

|April 20, 2005 |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| | |

| |[pic] |

| |[pic] |

| |Project Management |

| |Leadership/Soft Skills |

| |Advice, Anecdotes and Case |

| |Studies |

| |[pic] |

| | |

| |[pic] |

| | |

| | |

| |[pic] |

| | |

| |[pic] |

| | |

Why the four seasons of project management? Are they mutually exclusive? Can't I feed the song birds in winter? I do not seek to make a dogmatic declaration of personality styles or work structures, or contrast these findings with rich research. Rather, these are reflections of governing styles and characteristics incumbent in an "actor" playing the role of project manager that we can each reflect upon.

|[pic] |

|[pic][pic] |

 

Each style has its characteristic strengths and weaknesses, and a project manager would tend to have shades of each characteristic in their individual repertoire (in Part 1, we looked at The Planner and The Expeditor/Coordinator). However, I've found that one tends to have a predisposition toward a specific style of project management, given specific stimuli and circumstances. I have found myself consciously adopting a different style depending on the business need, with one leading style accompanied by shades of others. The cognizance of such diversity enriches the "management" dimension of project management, helping us look beyond the rule book. Hopefully we will all find an opportunity to be flexible in our styles, adapt as the situation demands and recognize how to align ourselves with our team member's styles and preferences. (And yes, you can feed the song birds in winter!)

 

The Analyst: Focus on the product

This project manager is more of an analyst, focused on the details of the product or deliverable. There is a direct domain-involvement that includes understanding, analyzing and contributing to the specific business need. This PM is interested in understanding and contributing to what is being delivered, not just when it is going to be delivered. While one might argue that all project managers are to an extent business analysts (being the bridge between client needs and delivery teams), some project managers are less of an analyst than others and tend to rely exclusively on the inputs of the analyst core, without diving into the details.

 

This management style is most commonly found with those who have a combined job role of business analyst/project manager, where they are expected to combine the dual functions. This style is most suited to product management, product marketing or internal line-of-business project management responsibilities, where domain knowledge is a sine-quo-non for informed decision making.

 

An asset to the customer, you can bank on this PM to challenge project teams to provide solutions, not just check off tasks on a task list. The analysts tend to be assets during the early phase of initiation/requirements gathering and during latter phases of testing/validation, with close line-of-business interaction. Analyst PMs are also good choices for managing projects with a high degree of uncertainty. Project management meetings might as well be dubbed product management meetings, since the PM is pretty adept and comfortable with delving into the product details.

 

It is quite possible that the constant focus on analyzing issues and needs, and finding solutions can lead to scope creep, so one has to be wary of PM-induced scope creep! A pure-play PM with this management style needs to focus more on work planning, and become comfortable with domain-level delegation.

 

The Leader/Manager: Focus on the people

This project manager, cut from the cloth of classical leadership, would be somewhat removed from the engineering approach to project management. The Leader/Manager focuses on understanding the people needs and interests in a project, with the ability to articulate a clear vision and provide direction. Somewhat of a hybrid of the above three styles, this PM seeks out and implements new management techniques and creates an environment of transformational leadership, constantly exhorting teams and customers to raise the bar of their own performance.

 

A master at delegation and inspiring action, this PM makes team members want to seek out and work on projects led by him/her. A motivational energy, you can count on this PM to provide a human angle to project management, and is constantly providing encouragement, guidance, counsel and direction to team members. Personnel development, satisfaction and morale metrics are important to the Leader PM, who plays a direct role in establishing reward and recognition processes. Typically, one might find more senior members of the profession in this style.

 

If you are a project manager, reflect on which of these characteristics are more dominating and which are not, in helping think through which mode you are more likely to follow than others. If you are team player, try to recognize which of these styles best reflect the style of your project manager. You might want to align your own style to complement your PMs, to ensure that you can fill in on the weaknesses of each specific style. For instance, if your project manager is a Leader/Manager, he/she might need support with creating detailed plans--volunteer to do that, and you will find yourself a valuable ally to the PM.

 

Effective project management requires finding a balance of all the above characteristics, but knowing which ones are more dominant than others might help team members better understand each other, and the interplay between themselves.

 

Author's note: The study of leadership has a long and rich history, with the studies, views and insights of researchers, practitioners and provocateurs of the subject. I am keen to continue this discussion with peers, professors and practitioners through gantthead to build upon these perspectives.



|Building a Solid Project Foundation |[pic] |

|Tim Jaques, PMP | |

|June 15, 2005 |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| |[pic] |

| | |

| |[pic] |

| |[pic] |

| |Project Management |

| |PM 101 |

| |[pic] |

| | |

| |[pic] |

| | |

| | |

| |[pic] |

| | |

| |[pic] |

| | |

Recently at a project management training class, the instructor faced his students and with a straight face said, "As project managers, we manage projects." Although the participants laughed, his point was not lost on the class--project management is often lost in the cacophony of the project itself.

|[pic] |

|[pic][pic] |

 

Project managers face the daunting challenge of defining, planning and managing projects in complex work environments. Stakeholders often send conflicting signals as to the importance and benefit of the project. Project managers need a way to navigate these waters so that the project progresses and customers receive maximum value at each project phase. Three key elements form the foundation of a project--the underpinnings from which a project can be successfully managed. The elements are 1) a common understanding of purpose, 2) executive support and 3) a sense of urgency about the project. Through understanding these critical components, project managers and team members can quickly cut through the morass of stakeholder issues to identify and resolve problems that could jeopardize the project. Consider the following factors:

1. A common understanding of purpose. Stakeholder alignment is the underlying theme. Project managers are usually concerned with defining deliverables and scope. Our stakeholders want to know how those deliverables will coalesce into their desired business outcomes and benefits. How long before those business benefits are realized and what is the cost? In the absence of a common understanding of the project's purpose, stakeholders will perpetuate their own versions, which are often in conflict with each other. Project teams can develop simple messages that describe the purpose of the project and how it links with the big picture. For example, "The server upgrade project will result in decreased processing time for all batch reports. This will increase processing capacity and increase IT staff time available for other work." Stakeholders identify with business outcomes. Using business terms and linking the project to a known problem or opportunity will help align the stakeholders under a common understanding of the project's purpose.

2. Executive commitment. Every major project must be sponsored by an executive manager. Commitment is best demonstrated through actions like securing funding and resources, advocating to other executives, setting priorities and resolving issues. A project assigns authority to the project manager to use resources beyond their usual scope of control for the purposes of completing the project. This authority is derived from an executive, so in the absence of demonstrable executive commitment, the project will often fail because there is no legitimate decision maker driving the project. Executives sometimes do not know how to display commitment for the project and do not understand their role in the project. The project manager can help by providing specific behaviors and direction that will demonstrate project commitment.

3. A shared sense of urgency. Project stakeholders should display a sense of urgency about completing the project. Not necessarily life-and-death, but urgency denotes the underlying resolve and commitment for completing the project. Not all projects are the top priority, and certainly a five-year effort presents problems on the urgency front. However, the project was originated to solve a business problem, and if that problem is real and compelling, it should translate into a sense of urgency from the stakeholders. Although stakeholders will probably vary in their degree of commitment, a critical mass is required to proceed with the project.

Experienced project managers know that projects often result in compromise. For example, deliverables are often sacrificed for lower costs or cost is often sacrificed to meet a completion date. These tradeoffs are the very business of managing projects. Caution is recommended when seemingly typical project tradeoffs reveal a deeper chasm between stakeholders. It may be worthwhile to revisit these project components with your stakeholders to be sure that any shifts in project direction do not fracture the foundation. What can we, as project managers, do with this information? The table below provides guidance in overcoming common challenges associated with your project foundation.

 

|Foundation Element |Signs and Symptoms of Problems |How to correct |

|A common understanding of purpose |•         The same words have different meanings |•         Complete or validate a Statement of |

| |(e.g., "requirements") |Work |

| |•         Stakeholders identify disparate outcomes|•         Clarify key concepts and words |

| |•         No defined, documented scope |•         Validate with stakeholders the |

| |  |project deliverables and long-term outcomes |

|Executive commitment to the project |•         Does not speak "on message" |•         Understand executive motives and try |

|  |•         Does not deliver on commitments |to accommodate |

| |•         Fails to resolve conflicts |•         Provide a discrete set of |

| |•         Either ignores the project or |responsibilities for the executive to fulfill |

| |micro-manages |•         Build and maintain an effective |

| | |working relationship |

|A shared sense of urgency |•         Lack of focus and energy for the project|•         Communicate how the project addresses|

| |•         Priority of the project is questioned |current business needs |

| |•         Stakeholders don't commit resources |•         Define the benefits in terms of the |

| |•         No clear champions for the project |problem or opportunity |

| |emerge |•         Set short term goals |

 

Using a common-sense approach to managing the foundation of your project will drastically improve the chances of success. Good luck!

 

Tim Jaques, PMP is a project manager with Keane, Inc. He can be reached at Timothy_W_Jaques@.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download