Project Management V Service Management Part 2

Last week I gave a talk on Project Management v Service Management at the IT Service Management Forum’s Conference here in Singapore. It wasn’t the best presentation I’ve done in recent years but the topic was a relevant one.

My most recent project, in the manufacturing sector, lasted 18 months and was not my most challenging from a project perspective. However it did highlight several areas that I come across on many projects, more vividly, than most.

The interface between Project Management and Service Management as it relates to the IT world, is broken. Yes, I know, we all know it, we’ve all known it for a long time too. In most cases Project folk like to maintain their unique role as special function and not be seen as art of a “service” organization.

Hey, I was like that too many, many years ago. It’s nice to be different from the crowd, have different responsibilities, and to be on a high profile job, like a major project. Well that’s all fine but it’s not good for the organization investing in the project and it’s a very inefficient way to operate. And here’s why:

Project Management v Service Management

Without a clear definition of the project deliverables that include the service management needs;

  1. customers requirements may not include support requirements resulting in the project delivering products and services that will not meet service and support needs.
  2. integration of change process between the two organizations is prone to problems and risks if not operated as one. This can and often does lead to clashes and delays as two organizations attempt changes relating to common infrastructure and operations.
  3. strategic business decisions that may influence the support model may not be fed into the project solution.
  4. project outcome may satisfy the initial requirements but be a nightmare for support services to manage and therefore prove a poor long term investment and not deliver to the business strategy 100%.
  5. handover of the project into an operational environment will prove more of a challenge than it needs to be.
  6. lack of “synchronization” between project management and support management will cause delays and increased costs against the project.
  7. Many process and procedures that the project organization need to use or interface with are inefficient for project work or are created specifically for the project and don’t interface or leverage the operational procedures that they need to become part of.

If you look at the ITIL model, the approach to the Service Life Cycle almost emulates the Project lifecycle at high level, in Prince 2. This is no accident. In business the strategies are discussed and presented. The design of a solution to deliver that strategy is worked out and then the solution is built. Once the new solution is in place, well, someone has t support it, don’t they?

It’s no surprise that the service management organization is key to the delivery of business strategies and in so doing encompasses a high degree of project management in the delivery f those strategies.

The link between project management and service management organizations is more like an intimate bond. So why is it missing in action in so many organizations?

I don’t have the answer here. I could speculate, based on many years of project management and service management experience. But I won’t, here, and now.

My message is this;

  1. Project scope and requirements must include the service management or support organizations requirements as well as the business needs.
  2. Management process and procedures that support a project should be aligned to operational procedures as much as possible. That means operational procedures need to be flexible and efficient in support project needs as well as operational needs. i.e. Procurement, Resource engagement, Financial reporting, Change Management etc.
  3. Project skills are not easily learned and are sufficiently different from a service management skill set that it pays to get experienced project managers on to major investment projects. However, never lose the opportunity to develop good service staff by attaching them to the project in assisting roles.

Project Management is about people, so is Service Management. Both have similar needs and common threads, both also require training and practice (experience) to become professional delivery agents.

Authority and Responsibility, How They’re Related and How They Affect Project Management

Veteran project managers know that they accept responsibility for the project when they accept the role of project manager. They also know that the lack of authority can seriously impede their ability to deliver the goals and objectives set for the project. Responsibility is directly proportional to consequences. Responsibility for project results doesn’t mean that they get placed on the bench until the next project if the one they’re leading fails, it has a monetary consequence. They will suffer with the project through elimination or reduction of bonus, a re-assignment to a less responsible role (with an attendant reduction in salary), or dismissal in the case of consultants. The connection between responsibility and consequences is entrenched in business. Larger more costly projects will tend to engage more senior project managers and the consequence of failure will be proportional. The connection between project results and consequences will also be heightened.

What is lacking in my experience (20 plus years as a programme and project manager) is a correspondence between authority and responsibility. Project managers can do much of the project planning without having access to authority. Project managers will need some help from subject matter experts for some of the planning work, even if it’s just to validate effort or cost estimates. Larger, more complex projects tend to have more need of subject matter experts to the point that some of the work is planned by these experts. The authority needed to acquire and manage the resources needed for this work will usually come with the territory. It’s when the project reaches the build or implementation phase that the project manager needs authority. They can plan the work, organize the work, and monitor performance but without authority they have a very limited ability to ensure the work is done on time and with the necessary quality.

The largest, most costly, most complex projects are led by project managers who hold senior positions in their organizations and bring that level of authority to their projects. The Manhattan project, which delivered the Atomic bomb during World War II, is a good example of this type of project and project manager. Leslie Groves, who managed the project, was a 3 star (lieutenant) General. The vast majority of projects which don’t fall into the Manhattan project category in terms of size are where the connection between authority and responsibility falls apart.

Most projects nowadays are executed in a “matrix” environment where the organization uses project managers to run projects and functional managers to manage people. The matrix environment is a good fit for most organizations because they have a mix of operational and project work. The problem with the matrix environment is that seldom do they come with a blueprint for the division of authority between the functional and project manager which means that the project manager has none of the authority and the functional manager has it all from the resource’s perspective. Organizations with more mature matrix environments may have taken some steps to resolve the issues that this division causes, but rarely do the definitions of the 2 roles include a precise description of authority. This is probably also due to the fact that the HR group plays a big role in defining authority through their policies and they tend to be behind the curve in accommodating their policies to the management of projects.

Problems start with the acquisition of the project team. Project managers are prone to the same greed and the rest of the human race and would like to have a free reign to acquire the best resources the organization has to offer. Functional managers, on the other hand, have their operational responsibilities to consider. They will be compensated for the resources they relinquish to the project but aren’t usually incented to make sure their best and brightest are made available to the project manager. That’s because their performance is measured based on the success of their operational responsibilities. If they make their best resources available to the project, they may fail to deliver on their operational goals and objectives and that may have a negative impact on their compensation. The best approach I’ve seen to balancing operational and project needs is to have functional managers whose sole responsibility is the “care and feeding” of resources. Since they don’t have any other operational responsibilities, they are free to assess the competing needs of projects and operations and make assignment decisions based on their perception of what’s best for the organization.

Problems encountered with team acquisition will propagate throughout the rest of the project. Presuming effort and duration estimates were based on some level of performance that is greater than some of the acquired team are capable of meeting, project performance will suffer. Pointing out to the project sponsor that performance issues are being caused by under-performing team members may or may not bring relief. The sponsor is likely to view your complaint with scepticism if you didn’t raise the issue before. An inability to perform the work is not the only cause of poor performance. By far the most common cause of inadequate performance is the bleeding of resource time from the project by operational demands. The demands may be quite legitimate and the operational work demanded of the resource may be the best possible use of that resource for the good of the organization. That doesn’t help the project manager when he or she has to explain poor project performance to the stakeholders. This situation is bad enough when the project manager is given notice of the demand but is much worse when they learn of the change after the fact. The level of authority the project manager has been given, or at least the functional manager’s perception of that authority, will often determine whether they find out about the operational work before or after the fact.

The other side of the resources coin is the recognition and rewards that are used to build team morale. A lack of authority in this area usually has to do with the project manager’s ability to spend money to give awards or purchase any other kind of team building activity. Recognition and rewards are usually governed by HR policy which is the reason the project manager is not given authority to bestow these on deserving team members. The lack of any kind of budget to buy awards is the other reason.

Lastly, the project manager may be called upon to deal with team members whose head just isn’t in the game. They have the ability, experience, and training to perform the work at the level of competency envisioned in the project plans but don’t. There may be a variety of reasons for this but they usually stem from the resource’s commitment to the project, or lack thereof. Let’s look at the example of a process improvement project to illustrate what I mean. The benefit of the process improvement is the elimination of effort which will translate into job loss (at least in that department). Some of the team members who work on this project may be the ones whose jobs will be eliminated; after all they’re the subject matter experts in the old process. Is it reasonable to expect these folks to show enthusiasm for the project? Of course not. Unless the project manager can show these team members how the project will benefit them, or at least not harm them they’re going to be less than committed to the objectives of the project.

The lack of enthusiasm may have nothing to do with security; there are any number of reasons for a lack of commitment from team members: jealousy, the perception that their best interests are served if the project fails, a commitment to a project they perceive as competing, dissatisfaction that a friend is not assigned to the team are just some of the “political” reasons that a team member may not give the project their best effort. Resolving any of these issues will require that the project manager have some degree of authority over the resource. This doesn’t necessarily mean they have hiring and firing authority, the ability to influence their compensation may be sufficient.

Now that I’ve made the case for an authority commensurate with the degree of responsibility, let’s look at some ways and means of acquiring that authority. I’ll start by addressing the folks who sponsor projects. You should hold your project managers responsible for project results; that’s their job, but it doesn’t make sense to hold them accountable without giving them the ability to meet the project’s goals and objectives and authority is a key component of that ability. You can help here by coming to an agreement with your project manager over the degree of authority you’re giving them. Working within the policies dictated by your HR group, you should assign them the authority level you both agree they need. Don’t speak in generalities, be specific. The project manager should know what their remedies are in the case where they have performance issues with team members. The process used for determining the composition of the project team should also be clearly articulated. How will disagreements over individual resources be resolved? Of course to do this in a way that makes sense for your organization, you’ll need to prioritize your project against the other projects and operational work of the organization. If the project goals and objectives are high priority, the project can’t be a low priority when it comes to competing for scarce resources.

Their level of authority over the team members, once the team has been defined needs to be clearly articulated as well. How will the project manager deal with a team member whose performance is sub-standard because they don’t have the necessary skills or experience? How will they handle the team member who has the necessary skills and experience but isn’t performing for some other reason? The project manager’s authority needs to be articulated in sufficient detail so that these questions are answered. Delegating authority to the project manager doesn’t have to contravene any HR policy. For example, it may be against policy to allow the project manager to hire or fire resources but where stakeholders, customers and others, contribute to performance reviews make sure the project manager is a contributor and make sure their review is weighted in accordance with the amount of time the resource spends on the project and the project priority. On the other hand sometimes projects are important enough and HR policies behind enough to warrant changing them. Don’t be afraid to gather political allies and make the case for change to HR. You may be successful in effecting the change for the next big project even if you aren’t successful making the change for the current one.

The project area that the project manager will need authority for is recognition and rewards. The project manager should be able to articulate a recognition and rewards programme for the project, or how they will utilize existing recognition and rewards programmes. Ensure they have sufficient authority to administer the programme. This will mean a budget, in most cases. Work out how you’ll make the money available when needed in cases where it’s impossible to give the project manager any signing authority. Lastly, make yourself available to take part in awards ceremonies or team building activities. I haven’t dealt with any sponsors who didn’t enjoy these occasions once they had been exposed to them.

Project managers who have sponsors that have failed to read the above, or who are not comfortable taking the initiative with you, will need to initiate the conversation themselves. Once you’ve defined the level of authority you need in detail make certain it’s documented. If your authority isn’t written down anywhere, you don’t have it. People’s memories being what they are, the perception that you have of the authority you have will differ from your sponsor’s and that gap will only widen as time goes on and memories deteriorate. Remember that the authority you’re given isn’t plucked from thin air, it is authority that your sponsor has (or any other senior stakeholder) that they delegate to you.

Your authority should be captured in the Project Charter. The level of detail need not be any greater than the rest of the charter; you can leave that to specific tasks or purposes. It should be spelled out in generalities such as “the Project Manager has the authority to participate in the selection of the project team”, “the Project Manager will evaluate members of the team and these evaluations will be used in performance reviews”, or “the Project Manager has the authority to address performance issues”. Specifics can be left until the project advances to the stage where authority is needed. For example, you can ask for an e-mail from the sponsor in advance of team acquisition specifying how decisions will be made on individual team members and how disputes will be handled.

Authority is like a muscle: it will atrophy if it isn’t used and won’t be available when it is most needed. Your sponsor has given you authority so that you can use it to achieve your project’s goals and objectives so you should never fail to achieve them because of a lack of authority unless you were specifically denied it. This means that when team members refuse to recognize your authority to direct their work you must use it to impose your will on them. Don’t confuse the imposition of your direction with abuse. You abuse your authority when you use it for purposes other than the accomplishment of the project’s goals and objectives or when you show favouritism imposing consequences or rewards. Avoid abusing your authority at all costs, but not at the cost of failing to exercise it. To ensure you avoid abusing your authority it’s a good idea to have your HR organization’s policies and guidelines handy and ensure you’re familiar with them.

Project managers who initiate the conversation about authority will have the advantage of being able to define the level of authority they believe they need. This can either be done by spelling your authority out in the draft version of the Project Charter or in some other document that precedes it. Don’t be faint-hearted here. It’s better to have authority that you don’t need and don’t use than to fail to have it and need it. Don’t be shy to exercise an authority you don’t have because neither you nor the sponsor foresaw a need for it. Your sponsor is much more likely to forgive you exercising an authority that leads to the accomplishment of a project goal than they are to forgive you for failing to meet the goal.

Most of what I’ve said here will apply to project managers who are permanent employees of the organizations they manage projects for, but what about consultants? These folks perpetually find themselves in “matrix” environments because even in organizations that are projectized or that have a mature, proven matrix arrangement, they don’t apply to the consultant. Consultants need to be especially diligent in outlining their level of authority and in using it. Their authority will never include the ability to fire or to pick and choose resources when acquiring the team. At most they will have the authority to hire contractors and participate in acquisition negotiations for employees so they need to ensure that they have a remedy that will address an insoluble problem with a team member. Don’t forget that when you first arrive on the job you’re an unknown quantity to the stakeholders. They may have had exposure to you when you interviewed for the role but you’re still an unknown quantity. After you’ve been in the role for a while you should have gained a level of trust that will allow you more leeway in exercising authority but until then don’t make assumptions that could embarrass your sponsor.

Finally, if you fail to have your sponsor delegate the authority to you that you need to succeed, make sure you document that fact. How do you do that without insulting your sponsor? Simple, not having the authority needed to achieve project goals and objectives is a risk to those goals and objectives and should be captured in the project’s risk register. Don’t describe these risks in personal terms; describe them in terms of what the risk event looks like and the likely impact on the project if they happen. A conversation about mitigation strategies to address the risk may lead to granting you the authority. At the least they should lead to a mitigation strategy that will reduce the level of risk. If all else fails and there is no granting of authority or identification of acceptable mitigation strategies, the project must accept the risk. You still have the option of reviewing this risk and its acceptance whenever the risk register is reviewed with the stakeholders. A word of caution here: the risk identifies a disagreement between you and your sponsor; don’t use this as an opportunity to embarrass your sponsor in front of their peers or managers.

One final word of advice for all project managers: it’s usually easier to ask for forgiveness than permission. When in doubt assume the authority and exercise it. If you’ve overstepped your bounds but achieved your objective your sponsor may point the mistake out to you, but won’t be as unhappy with the result as they would be if you failed to exercise the authority and failed to achieve the objective.

CMM and Project Management – Tracking and Oversight

The goal of the Software Project Tracking and Oversight Key Process Area (KPA) is to provide sufficient insight into project performance so that the project manager can detect variances between performance and the plan and take preventive or corrective action. This KPA influences all PMBOK knowledge areas and is most closely associated with the Monitoring and Controlling group of processes. As with the other KPAs Software Project Tracking and Oversight is organized into goals, commitments, abilities, activities, measurements, and verifications.

Goals
The goals of this KPA relate to and support project oversight and corrective actions. The goals are that results are tracked against project plans, that corrective actions are taken when there is a variance between planned results and actual results, and that corrective actions that change the project plan are agreed to by the affected groups. The abilities and activities all support the achievement of these goals.

Commitment to Perform
Commitments to this KPA are required at the executive level. The first commitment is that a software project manager be assigned to the project. This commitment will be made by default for most IT projects. The project manager responsible for the entire project is likely to be someone who is considered a “software project manager”, or at least has experience managing software projects. When larger projects require a sub-project for the creation of a software system or application to be defined, this commitment requires a project manager to be assigned to manage the sub-project. This is an organizational commitment, but might require you to identify and assign a project manager to manage the software sub-project if you are the overall project manager.

The second commitment is also at the organizational level and it is that project management follows a written organizational policy for managing software projects. PMs working out of a PMO or PMC should have such a policy to follow. If you are a project manager leading the charge for CMM/CMMI certification you should undertake the writing of this policy to govern your project and future projects for your organization.

Ability to Perform
There are 5 abilities required to meet CMM/CMMI level 2 criteria. The first ability is that software project has a project plan. The second is that the software project manager assigns work to the project team. This means not only that the project manager defines, organizes, and schedules the work in their plan, but that they direct individual team members to do the work. I believe that meeting the criteria for this ability requires the software project manager to be given the authority to direct the project resources work for the duration of the project. The best way for this authority to be officially granted is through the Project Charter which governs the project.

The third ability calls for adequate resources to be provided for tracking and oversight activities. Planning of the activities will be supported by the project’s plans and schedule. Adequate funding will be demonstrated by the budget for resources to perform oversight and tracking activities being part of the approved project budget. Ability 4 requires the software project manager to be trained in managing the “technical and personnel aspects” of the software project. I would argue that there is no better way of demonstrating this ability than by the certification of the software project manager as a Project Management Professional (PMP®). The Project Management Institute oversee this certification and are recognized globally as the leaders in the area of project management certification and project management best practices. Certification of your software project manager is straight forward, providing PMI’s criteria for project management experience are met. Providing they are, the project manager can choose from a host of quality PMP® courses or PMP® exam preparation training products to prepare them for the certification exam. These courses will train project managers in Project Management best practices and their implementation, as well as helping the project manager pass their exam.

The final ability calls for first-line software managers to receive “orientation in the technical aspects of the software project”. CMMI defines a first-line software manager as someone who has direct management responsibility, including responsibility for providing technical direction, for staffing and activities of a single organizational unit. This definition matches the PMBOK®’s definition of a functional manager. The first-line manager should be educated in the tools, processes, procedures, and standards used for the project.

Activities
Activities called for by CMM include:

  1. Use the project plan for tracking activities and communicating project status. The plan should be updated with information for work completed and made available to project stakeholders. Your MS Project file will satisfy this criterion and will convert your WBS/schedule to several formats that can be accessed by stakeholders who do not have MS Project on their desktop.
  2. The project plans are revised according to a documented procedure. This procedure will be your Change Management plan, or Integrated Change Control System (ICCS). The various components of the project plan specify how changes approved by the ICCS/Change Management plan are to be implemented. The activity also calls for a review of the revised project plan.
  3. Commitments made to external groups, and any changes to those commitments, are reviewed with senior management according to a documented procedure. In the context of tracking and oversight this activity will be described in the project’s Change Management plan.
  4. Approved changes to the software project are communicated to the members of the software engineering group and other software-related groups. Your Change Management plan, or Communications Management plan, should describe this.
  5. The sizes of work products, or changes to the work products are tracked and corrective actions taken as necessary. CMM uses the word “size” to refer to the number of lines of code,.html pages, or pages of documentation produced. The idea is to compare the actual size with the estimates for the purpose of identifying actions required to correct the estimation procedure and future estimates.
  6. Effort and costs are tracked and corrective actions taken when necessary. The cost management portion of the project plan will govern monitoring and controlling expenditures and identify how corrective actions are to be identified. The Change Management plan governs how changes to the cost estimates are to be made. Since software development projects frequently aren’t governed directly by budgets, this may be accomplished in the Time Management plan for the project.
  7. Critical computer resources are tracked and corrective actions taken when necessary. These will be tracked, along with other project resources, in the resource management plan.
  8. The schedule is tracked and corrective actions taken when necessary. The Time Management portion of the project plan will describe how this happens, including the analysis of late and early delivery dates on the plan.
  9. Technical activities are tracked and corrective action taken when necessary. Technical activities refer to the methods, procedures, and processes used to develop and test the software. Testing activities will be described in the Quality Management plan. Most of the methods, procedures, and processes associated with development of the software should be captured in the Configuration Management plan. Activities not covered by the Configuration Management or Quality Management plans should be described in a separate plan.
  10. Project risks are tracked. This is accomplished by the Risk Management plan
  11. Measurement data and re-planning data are recorded. This includes estimates and data associated with the estimates, plus data measuring completed work. Estimates will be captured in the WBS and schedule. Estimating tools and methods such as Function Point Analysis (FPA) will be described elsewhere.
  12. The software engineering group conducts periodic internal reviews to track technical progress, plans, performance, and issues against the plan. The software engineering group includes the first-line managers and software project manager. This activity is covered by your weekly status review meetings.
  13. Formal reviews to address accomplishments and results are conducted at selected project milestones. These formal reviews will correspond to your Gate Reviews.

Measurement and Analysis
The effort required to perform the tracking activities is measured

Verification
Verification is performed by senior management who review the tracking and oversight activities periodically. This will be satisfied with the Gate Reviews planned for the project and by any Steering Committee or Project Sponsor reviews scheduled. Verification is also done by the project manager. This requirement can be satisfied with regular status review meetings in addition to the Gate Meetings. These two verifications also require you to produce a status report after each meeting.

The 3rd verification calls for reviews or audits of the project by a Quality Assurance group. Since CMM regards the Quality Assurance group as an entity outside of the control of the project, the senior management of your organization should be responsible for this verification. If you are assigned to manage the project by a PMO or PMC this group may provide the audits or reviews required by CMM.

The tips and tricks described in this article implement some of the best practices promoted by the PMI (Project Management Institute). These are taught in most PMP® courses and other PMP® exam preparation training products. Visit the three O web site for a sampling of some of the products available in this area, including AceIt©, our downloadable software training tool: http://threeo.ca/featuress8.php