CMM and Project Management

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:

Use the project plan for tracking activities and communicating project status. The plan should be updated with information for work completed and made available t

Organistational Factors

Project Management and Organistational Factors

In this article we will discuss organizational influences on project management

Every organization has its own culture, style, leadership approaches, and employee personalities that make it unique. These organizational characteristics greatly influence how projects are performed and managed.

This module will focus on different organizational cultures and styles and their impact on projects. In addition, we will discuss communication within the organization and how different styles can impact how projects are conducted, next we will review the impact that organizational structure has on how projects are performed and finally, we will examine organizational process assets and enterprise environmental factors.

Organizational Cultures and Styles

Organizations are unique and create their own cultural norms and styles for performing their operations. The norms and styles also impact project management, especially influencing the initiating and planning phases of the project. How the work is performed and who makes the decisions for the project will also be influenced by the culture of the organization.

Cultures and operational styles are considered enterprise environmental factors. We will discuss these factors and their importance in Module Four. The cultures and routine operational styles will impact the project’s ability to meet the objectives, stay on budget, and finish on time.

Project managers need to understand the organization’s culture in order to effectively plan projects for success. Culture also plays a valuable role in project management since many companies are now global and the project teams often consist of various cultures, so managers must recognize these differences and bring the team together.

Organizational Communications

One of the most important elements of project management success is communication. The organization’s communication style will have a major impact on the success or failure of potential projects. Project managers need to recognize the communication style of the organization and determine the most effective approach.as email, instant messaging, face-to-face meetings, and social media can all be considered. If there are virtual team members, a strong emphasis must be placed how the team will work and communicate to ensure that everyone stays informed of the project’s status and has access to all relevant information, both formal and informal.

Organizational Structures

Organizations spend a great deal of time deciding on the operational structure that will work best for them. Organizational structure is another enterprise environmental factor. The structure is directly related to the availability of resources, decision-making, and the operational performance of the project’s tasks.

There are three main types of organizational structures: Functional, Matrix, and Project based. The functional structure is usually described as a hierarchy. Employees have one clear superior and the support staff are grouped by department or specialty. Each department has a certain function that it performs within the organization and often performs its work independently of other departments.

Matrix organizations are a mixture of the functional and project based structures. Matrix organizations are broken down into weak, balanced, and strong depending on the project manager’s authority level. In a weak matrix, the role of the project manager is transformed into a project coordinator or expediter. These would be considered support roles and the individuals would have very little control or authority.

The final organizational structure is the project based structure. In this structure, team members are often located physically together or connected virtually. In this structure, project managers are given a high level of authority with the team members collaborating and reporting to the project manager,

In some instances, organizations will combine all three of these structures together into a composite organizational structure. The team will be comprised of full-time workers from other departments who eport to the project manager, however, they will likely still perform their normal day-to-day activities.

Organizational Process Assets

Organizational process assets include plans, processes, policies, procedures, and knowledge bases specific to the organization performing the projects. These processes include the practices and knowledge the organization has that can be used during new project phases. Organizational processes often come from the archived information about past projects and include risk data, schedules, and budget information. During new projects, the project team members will add to these processes and knowledge base to assist future projects.

Organizational process assets are placed into two categories: processes and procedures and the corporate knowledge base.

Processes and Procedures

The processes and procedures are

Project Management

Transition to Critical Chain Multi-Project Management

Transition to Critical Chain Multi-Project Management for Long Duration Projects

What to Do Until Buffer Management Kicks In

Abstract

The transition from traditional project management to Critical Chain Project Management (CCPM) in a multi-project environment presents a formidable problem with projects of long duration. A simple method is presented for that transition and provides the metrics necessary to directly encourage and cement the behaviors needed for Critical Chain Multi-Project Management. This paper assumes the reader is familiar with CCPM.

The Multi-Project Implementation

This paper focuses on the period of time from planning the first Critical Chain (CC) project, the cut-over project, to completion of the last traditionally managed project. This can be a long period of time before the company has fully implemented Critical Chain Project Management. Theory of Constraints (TOC) practitioners involved in Critical Chain Mulit-Project Management (CCMPM), often find this transition to be the toughest part of an implementation.

The Implementation Conflict

In order to successfully implement Critical Chain Multi-Project Management, we must obtain support for it. Everyone expects that CCPM will be another flavor-of-the-month implementation that fades away if properly ignored. To obtain that support, we must start with one project to prove that CCPM works. And to be successful, we must change the whole project system to CCMPM. Because Critical Chain requires Buffer Management and traditional projects can’t use it, we must implement CC on all projects at the same time.

Implement One Critical Chain Project First

Even though we know it works, we must prove that it works “here!” A common solution is to use a pilot (trial) project as a way to demonstrate CCPM and get the bugs out of the existing system. One project at a time is much simpler to implement than many. The pilot project should not be thought of as a trial. It’s really the first Critical Chain (CC) project, the cut-over project. Every new project following it will also be a CC project.

Typically, for a transition, the cut-over project is planned while the work-in-process is ignored. But in a multi-project management environment, that means that some or many shared resources will be fought over by the CC and non-CC projects. The resources are usually expected to multitask and have several projects in work at one time. Multitasking is a huge factor in projects being slow. How can scarce resources be assigned where they are most needed, if the statuses of these projects are measured differently?

The common approach to adding a new project to the pipeline of projects is to commit to a date and put it in the system. With little understanding of the amount of work in the system and the system’s capacity, work is pushed in with the expectation that it will get done.

With a system full of work-in-process projects, it will take a long time to complete this first CC project. Continued multitasking between projects will assure it. The reality is that people are asked to not multitask on the CC project while they are multitasking on the others. The non-CC projects will delay the faster, CC project. It will be difficult to determine and measure the Critical Chain project’s success compared to the others. Some people will believe it gets special attention and will demand to share its resources.

The more difficult problem is the lack of Critical Chain buffer management. Lacking CC project buffers, traditional projects can’t use buffer management. Priorities among the projects may be determined by perceived urgency as expressed by the project managers. Implementing the first Critical Chain project has not always been easy.

Big Bang Approach

The whole project system can be changed in one massive replan of all projects. It may make a lot of sense since we know we won’t be done until all the projects are CC projects. All projects are measured the same way and they quickly get up to speed. Or do they? How does the whole system get changed? All of the projects must be re-planned and changed to CCPM by shortening the duration of many, many tasks of many projects.

In a small system, the big bang approach is a real option. In a large system, it is definitely much more challenging and probably not possible. To change all the projects to be Critical Chain projects requires re-planning while they are in progress. The same people that are working the projects are need to do the replan. It’s likely to be chaotic and it won’t happen overnight. Re-planning will delay the implementation, delay current projects and may jeopardize an initial (or any) success. Just the opposite of what was intended.

Delay Until the System is Ready

Do not insert the cut-over project until the resources can focus on it. Prioritize the projects. Since any prioritization is effective in increasing the speed of a system, use the comm

Construction Companies

Benefit From Project Management Professionals (PMP)

Eighty percent of construction companies fail within the first two years, with another 18% joining their ranks in another three years.

There are various reasons that lead to a construction company going in trouble, including general economic conditions, not being competitive, heavy operating expenses, poor accounting system or even high employee turnover, but none impact a construction business as significantly as lack of project managerial expertise.

The Project Management Professional (PMP) certification is for project managers with extensive experience. Qualifications and testing criteria are rigorous, making it a widely respected certification. Generally speaking, construction projects are run by contractors, not by certified Project Management Professionals (PMPs).

The contractors would say that they’re the only ones who truly understand construction, because they’ve been there and done that; but, is that viewpoint valid? Where does the need for hands-on experience end, and the need for rigorous and structured project management ability begin?

Most contractors, whether general contractors or specialists (plumbers, electricians, etc.), worked their way up in the construction business. That means they started out as an apprentice, became a journeyman, possibly were promoted to being a crew chief or jobsite superintendent by the company owner, then eventually stepped out on their own to start their own company and be a contractor.

Here are 5 basic areas in which these contractors and Professional Project Managers think differently. These areas can make or break a project, specially when it comes to maintaining the project on schedule and on budget:

1 – Bidding Strategies and Change Orders

The world of construction is highly competitive, especially in today’s economy. Each job out there has a number of contractors bidding on it, driving prices down and all but eliminating profit margins. A common strategy which many contractors are using today is to bid the job with minimal overhead and negligible profits, depending on “Change Orders” to make their profits.

While this strategy works, it may not be working quite as well as many contractors would like. The very fact of bidding a job in that manner means that there is little room for error. Even a slight error in scope management, cost estimating or scheduling can take a project from profitable to being a loss.

If the project is being provided under a contract, then some advance thinking has to go into how to deal with “Change Orders” when they occur. Project Management Professionals approach Change Orders with a different mindset, since they see this as a change to the original “Plan” and seek to integrate the change into the overall plan instead of “tacking it on top of” work that is already being done.

Approved change orders can require revised cost estimates, new schedule updates, revised activity sequencing, additional risk analysis and even calculation of cumulative impacts. Therefore setting up a “Configuration Management” process with integrated change control provides an effective way to centrally manage and document change orders, while providing opportunities for increased profit margin.

2 – Claim Management

Although this may seem the same as the change orders (mentioned above), it is actually a separate area. “Change Orders” deal with changes for which both the owner and contractor are in agreement. “Claims” deal with areas where there is disagreement. These are extra charges due to unforeseen problems on the project, which the contractor wishes to recoup from the owner at the time of project closing. What makes these claims challenging is the difference in interpretation of the project scope. The owner may feel that these unforeseen situations are part of the scope of the contractor, while the contractor may see them as extra costs he incurred, for things outside of his control.

Effective claim management requires thoroughly documenting the problem, sending on-time notifications to the owner, including estimates of cost and schedule impacts, along with creating a convincing justification for the charges. This is one of the most challenging communication problems on a construction project. Project Management Professionals are trained in dealing with claims, whereas the typical contractor is usually at the mercy of the owner.

3 – Thinking “Tasks” instead of “Processes”

Eighty percent of construction companies fail within the first two years, with another eighteen percent joining their ranks in another three years. It’s not the lack of knowledge in construction, but the lack of knowledge in how to manage their projects. This article describes how construction companies benefit from Certified Project Managers.

A contractor or construction superintendent usually becomes such because they know how to do the job. But, that isn’t the same thing as knowing how to m

Project Management Best Practices

Project Management Best Practices

As both an active project manager and a project management trainer, people often ask me what are the fundamental aspects to successful project management. Whilst there have been many great books written on the subject, I always summarise what I believe to be the best practices at the heart of good project management.

Define the scope and objectives

For any project to be successful you need to understand what the project is supposed to achieve. Suppose your boss asks you to organise a campaign to get the employees to donate blood. Is the aim of this to get as much blood donated to the local blood bank? Or, is it to raise the profile of the company in the local community? Deciding what the real objective is will help you to determine how you go about planning and managing the project.

The project manager also needs to define the scope of the project. Is the organisation of transport to take staff to the blood bank within the scope of the project? Or, should staff make their own way there? Deciding which activities are within the scope or out of scope of the project has a big impact on the amount of work which needs to be performed during the project.

An understanding of who are the stakeholders is also crucial if you are going to enlist their support and understand what each person expects to be delivered from the project. Once you’ve defined the scope and objectives, you will need to get the stakeholders to review them and agree to them as well as agreeing who should be on the list of stakeholders.

Define the deliverables

To achieve the desired outcome from the project, you must define what things (or products) are to be delivered by the end of the project. If your project is an advertising
campaign for a new chocolate bar, then one of the deliverables might be the artwork for a newspaper advert. So, you need to decide what tangible things are to be delivered and document in enough detail what these things are. At the end of the day, someone will end up doing the work to produce the deliverable, so it needs to be clearly and unambiguously described.

Once you have defined the deliverables, you will need to have the key stakeholders review the work and get them to agree that this accurately and unambiguously reflects what they expect to be delivered from the project. Once they have agreed, you can begin to plan the project. Not defining the deliverables in enough detail or clarity is often a reason why projects go wrong.

Project planning

This is the time when you define how you will achieve the desired outcome of the project embodied within the objectives and definition of deliverables. Planning requires that the project manager decides which people, resources and budget are required to complete the project. You will need to decide if you will break up your project into manageable phases, decide which products will be delivered in each phase, and decide the composition of your project team. Since you have already defined the deliverables, you must decide what activities are required to produce each deliverable.

You can use techniques such as Work Breakdown Structures (WBS) to help you to achieve this. You will need to estimate the time and effort required to complete each ctivity, dependencies between related activities and decide on a realistic schedule to complete the activities. It’s always a good idea to involve the project team in estimating how long the activities will take since they will be the ones actually doing the work. Capture all of this into the project plan document. You also need to get the key stakeholders to review and agree to this plan.

When developing the project plan, a project manager is often under pressure to produce a plan which meets the (unrealistic) expectations of some of the stakeholders. It is important here that the project manager comes up with a realistic schedule – one which he/she thinks is realistic to achieve. You will be doing nobody a favour if you succumb to pressure and agree to deliver the project in a totally unrealistic schedule.

Communication

Even the best made project plans are useless unless they have been communicated effectively to the project team. Everyone on the team needs to know exactly what is expected of them, what their responsibilities are, and what they are accountable for. I once worked on a project where the project manager sat in his office surrounded by big colour print outs of his latest plans. The problem was, nobody on his team knew what the tasks and milestones were because he hadn’t shared the plan with them. Needless to say the project hit all kinds of problems with people going off and doing the activities which they deemed important rather than doing the activities assigned by the project manager.

Tracking and reporting project progress

Once your project is underway and you have an agreed plan, you will need to constantly monitor the actual progress of the project against the planned prog

Project Management

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 ar