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

Small Business Project Management: Six Pros and Cons

Growth hungry small businesses today in the UK and indeed throughout the world face the challenge of balancing two competing objectives. Firstly, businesses must maintain and standardise current business processes in order to give your business the chance to get really good at what it does through experience curve effects. Greater business efficiency normally translates into a better customer experience and higher profits. Secondly, businesses must transform business operations in order to survive and compete in the future. How well we are able to achieve the right balance for our business will ultimately determine if we survive and go on to thrive or go the way of so many small businesses into market irrelevancy and insolvency.

You may well be thinking right now what has this got to do with project management? To understand that we first need to understand the fundamental differences between projects and day to day business operations. Whilst many of the skills required to manage your “business as usual” activities are the same as those needed to manage projects, there are some crucial differences. Amongst the most significant differences are that project work tends to be at least cross functional and often cross organisational and every project will be unique in some way rather than following the predictable pattern of business as usual. These characteristics of projects introduce opportunities and risks over and above those encountered in business as usual. In short, projects are riskier than day to day business, and therefore need a different management approach.

Projects are the means by which we introduce change in organisations. All businesses that are making any attempt to adapt to face future challenges have projects. Common examples of projects in small businesses may include setting up a company website, establishing the office in a new location, or implementing a new product but it can be any temporary activity or set of activities that have a specific output associated with it. Businesses increase their productive capacity one project at a time. Indeed, for ambitious small companies looking to grow and expand, the need to initiate the right projects and achieve the desired results is even more vital l than it is for huge national and multi-national businesses

Despite the obvious need for a project management (PM) approach, most small businesses don’t bother. This constitutes a huge missed opportunity as effective project management impacts the bottom line. For example, research by the CBP shows that project management improvement initiatives improve project performance by up to 50% for the first project and can continue for each new project if the business offers ongoing project management tools and support. We could emphasise this point further by citing the Standish Group, who in their CHAOS Report conservatively estimates that 20% of money spent on projects is wasted because companies don’t have a consistent approach to project management.

Let’s take a look at six reasons I often hear from small business owners that choose not to bother with project management and then critically address the misconceptions behind these reasons.

1. Project management practices take more time

Having a process to follow may add time to the duration of an activity. Doing something properly will almost always take a little bit more time than adopting a slapdash approach. However, if you where building a house, would you rather have a quality end result that took a little longer, or would you prefer to have it done quickly but with lots of problems? Given that poorly executed projects can be completely de-rail a small business if they go badly, doing it well is essential, and PM processes help ensure things are done well.

2. Project management eats into the cash that I need to grow my business

A common misconception is that it is hugely expensive to implement PM process. The reality is that there are many free or low-cost sources of advice, techniques, tools, templates and project management services readily available and accessible through the Internet. If done correctly, any small business can implement PM processes, techniques and tools with very little cost. The likelihood is that small business owners are already using software and other tools that can be used for project management. For example, certain email software, spreadsheets, and other common software applications offer good templates for project management, especially if used in collaboration with some of the low cost project management services available for small businesses

3. Project management requires skills that I don’t have and cannot afford to hire

Although it does require specialised skills and experience to be an accomplished project manager, these are skills that can be learned over time. To move further up the learning curve faster, it is possible to take a PM course in as little as four or five days. Most small business owners tend to possess the knowledge needed for project management, and courses such as the Prince 2 Practitioner course would build on these skills while introducing the specific theories, tools, and processes essential for project management. Whilst business owners might not emerge from a course as a project expert, they would certainly learn valuable skills to apply to their small business.

4. I don’t need the hassle or paperwork of project management.

Every entrepreneur that starts their own business will, at some point, need to do a risk assessment, a marketing campaign or apply for finance. Being knowledgeable in project management and applying associated tools such as stakeholder analysis, communication planning and risk management will not only assist in many of these tasks, but will provide your small business with a competitive edge over competitors who do not approach.

5. Project management will slow me down and I need to stay agile.

Modern PM methodologies all acknowledge the importance of a tailored approach to project management. If your project requires speed, the right methodology can enable you to move quickly. Just as important, however, it will provide you with techniques to understand whether some proposed projects are worth pursuing at all. Rushing into situations without thoroughly understanding your environment is hazardous to the health of any project and potentially to the health of the business as a whole

6. I am an expert in my industry, I don’t need project management.

Most small businesses are started by a person who already has some expertise in their industry. This is unquestionably an advantage; however, project management should still be used to convert plans into reality. The main reasons for project failure tends to be poor planning, lack of capital, and lack of management. Project management, while not a cast-iron guarantee of success, will assist the small business in mitigating some of the common risks that so often cause project failure amongst small businesses.

Even a brief look at the reasons often posited by small business owners for failing to approach projects in a systematic and different way that recognises their inherent riskiness and addresses some of the more challenging aspects of project work shows them to be of dubious merit. Without question, the quality of project outputs would be greatly enhanced and the cost of and time taken in delivering project benefits using a project methodology appropriate to the scale of the project.

The Ten Commandments of Successful IT Project Management

Even with the best of intentions, managing projects in the Information Technology arena will always include elements of chaos. As a Project Manager you have a responsibility to effectively manage your project in a way that meets customer and stakeholder expectations.

Managing the expectations of your customers and stakeholders is just as important as understanding the vision and expectations of the initiative. Because you most likely do not have control over many of your resources, Stakeholders, Customers and Sponsor – identified process is the way in which you can successfully manage technical projects.

Identified process and communication of identified process will provide the parameters, expectations and the governance you need to be successful. In my experiences, failed projects all have had the same common thread; there was either a lack of defined process or identified processes were not properly communicated and adhered to. The good news is defined project management processes are available and made to be leveraged. The Project Management Institute (PMI) and Capability Maturity Model Integrated (CMMI) offer best of breed industry standard process in both Project and Organizational Management.

A project is defined as is a temporary endeavor with a defined beginning and end and often constrained by funding or deliverables. The following ten principles are essential and must be utilized for your project to succeed.

1) Sponsor / Business Commitment.

The Project Sponsor has the most interest in the project; in most cases the project is fulfilling business needs for the sponsor. Therefore, the Project Manager and Project Sponsor have a partnership and shared interest in the success of the project. In addition, the Project Sponsor usually controls resources and works directly with or supports the Project Stakeholders. Usually Project Sponsors are not understanding of the level of detail and commitment needed to successfully manage a technical project. The Project Sponsor must be engaged and fully understanding of the project scope and approach. In as much as the Project Sponsor needs to understand your commitment and approach, you need to understand the Project Sponsors commitment and expectations. Through the Project Sponsor, the business group must also have a clear understanding of their needed commitment and project approach. If the program does not understand and has not allocated time needed for their tasks, the project will most likely be delayed. A knowledgeable business team member will be required in many of the project phases including: analysis, JAD sessions, planning, design and testing.

2) Stakeholder Identification.

All stakeholders meaning all people affected by the project and or initiative must be identified. This is critical. Even successful projects can be a disaster if the initiatives are not understood at an enterprise level.

3) Project Scope.

It is critical that every project have a clearly defined scope that details all deliverables in relation to the business needs being met. The scope will be agreed on by the sponsor and all stakeholders, including Project Team Members. Any changes to the project scope will be addressed through the change management plan (discussed later).

4) Project Requirements.

Every project will need identified project requirements; the level of detail will depend on the complexity of the project. Generally, project requirements consist of functional (business) and technical requirements. The functional requirements address the business needs and may include: use cases, process flow diagrams, data needs, reporting needs, gap analysis, testing requirements and other documentation that accurately identifies the business needs. Technical requirements leverage the functional requirements with consideration to any technical standards and policies of the organization. Technical requirements may include: data base diagrams, architectural diagrams, screen shots, performance requirements and other technical specification and design documents needed to procure or develop the desired solution. It is understood that requirements are developed through analysis which will include Joint Application Design (JAD) sessions as well as interviews and or review of existing documentation. Both functional and technical requirements are to be reviewed, understood and approved by the designated project management Team.

5) Detailed Project Plan.

Contrary to popular belief a project plan is not just a Microsoft Project gantt chart/mpp file. A true project plan will consist of the following documents:

• Project scope – defined above

• Project requirements – Defined above

• Communications plan – A Communications Plan will identify all stakeholders who will receive communications, the level of communication, the method of communication and how often. This is important to set the expectation of how your stakeholders will be communicated with.

• Risk management – this document will qualify and quantify risks and how they will be mitigated.

• Gantt chart/project/cost schedule. This document; commonly referred to as the project plan will include time estimates, dependencies, milestones and identified resources. The gant chart includes the scheduling, dependencies and resources needed. This is the document that will be referred to when managing the schedule.

• Issues list/ action items. As issues are identified they will be included in the issues list, assessed and prioritized. The project team will determine how the issues will be addressed.

• Change Management Plan – The process in which scope change will be handled (described below)

6) Change Management Plan.

A change management plan identifies the processes involved when a requested change affects the project scope, requirements and or schedule. Typically the requested change, resolution, needed resources and project impact is identified by the project team. The final decision on how the request is handled is usually provided by the Project Sponsor and or Stakeholders.

7) Project Baseline

It is recommended the project be saved to a baseline. The baseline identifies the schedule and saves it. Any deviations from the base-lined schedule shall be identified and reported as part of status reporting.

8) Project Monitoring and Reporting.

Status reporting shall be done on an identified basis (determined in the communications plan) and include statuses regarding the schedule, cost, resources and any other issue which impact the project. In most cases an Issues list is employed to track identified issues and how the issues will be resolved in the form of a stated action.

9) Exception Management.

In as much as we would like things to go according to schedule, they rarely do. Exception management is a must and includes all actions relative to managing project exceptions. Exceptions include, project variances, schedule variances, scope change, resource issues, personnel issues, personality issues and any other issues you can think of.

10) Needed Skill Sets

To be most effective a Technical Project Manager should have a thorough understanding of: project management process, technical knowledge, and organization and communication skills.

Project Management is as dynamic and rewarding as it can be gut-wrenching; my advice- expect both. I hope this article provides assistance and a realistic reference for you to be most successful managing your projects.