Monthly Tidbits

 

TINY TACTICS TO SAVE TIME AND MONEY

Every week we visit clients, help solve their problems and share information. Since many of the challenges we see are common across organizations, we share one or two of them each month with example solutions.

Tidbit #1: Writing Clear Requirements - One Requirement Per Sentence

Tidbit #2: Agile, Just Code and Ship, Merging with CMMI

Tidbit #3: Improving Your Service Delivery with CMMI® for Services* - Quick Look

Tidbit #4: Measuring a Process

Tidbit #5: Where do you Spend Your Time – Fulfillment or Demand?

 

Tidbit #6: Project Planning and Monitoring & Control for a Services Organization

---

Tidbit #1: Writing Clear Requirements - One Requirement Per Sentence

Having requirements for a project is essential to clarify the desired end goal and eliminate work that does not serve the end user. However, the majority of the requirements documents we review are pages of long narratives that obscure the intended end result. An example is:

Pay for product: The system should allow entry of data items relevant for customer payment, or allow a user ID to be entered to charge the amount to. If an ID is used, and there are insufficient customer account funds, then either request a credit increase or notify that the account is overdrawn and flag the account as 'credit-line'. Email a receipt of the transaction.

The problems with a paragraph-style requirement are that:

• It takes an engineer a long time to thoroughly understand the requirement.

• The multiple "and" and "or" words add ambiguity, since the requirement, "Do A and B or C," might actually mean only one of several possible combinations. If these are misinterpreted, then the misinterpretations are implemented as defects that are expensive to detect and correct later.

• It contains multiple requirements, some of which will be lost and forgotten by the implementer and have to be re-discovered later in test. For example, "Email a receipt of the transaction" might get lost.

• Test cases are difficult to generate that fully validate each requirement.

In this requirement, the options offered to the user are confusing since it is unclear whether the account should be automatically overdrawn or whether the user should be given other choices first.

Alternatively, one could rewrite the paragraph, specifying one requirement per sentence. For example:

1. Pay for product
1.1	User selects a) pay with credit card or b) debit ID account
1.2	User enters a) credit card or b) ID and password
1.3	If b) and insufficient funds in the ID account then offer user a credit increase option
1.4	If credit increase option selected then notify that the account is overdrawn
1.5	If the account is overdrawn then flag the account as 'credit-line'
1.6	Email a receipt of the transaction

In this style, we use one line per requirement and limit each requirement to one "and" or one "or" to avoid ambiguity. This makes the requirement quicker to read and understand. Test cases can be generated and mapped to each line of the requirement.

[Top of page]

---

Tidbit #2: Agile, Just Code and Ship, Merging with CMMI

The interest in Agile software development practices continues to grow as companies seek more efficient methods of developing software while meeting market demands for delivery.

Scrum is a software development methodology based on Agile principles. Agile methodologies promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy using teamwork, self-organization and accountability, with strong customer involvement*.

We have seen companies improve their performance using Agile, CMMI, and other frameworks. In this tidbit, we discuss two common questions that we hear when visiting clients and prospects:

1. "Agile in my company means code and ship, avoiding requirements and design; what shall I do?"
2. "My company is trying to use CMMI, and now it wants to consider Agile; what shall I do?"

 

1. Agile in my company means code and ship, avoiding requirements and design; what shall I do?

If the only development activities are coding and some test, then we call an organization "Agile declared", not Agile! Although Agile is intended to speed up a project's progress, it still includes basic engineering and management steps.

Whether your organization chooses an Agile approach, Waterfall or an incremental life cycle, activities such as requirements and design are performed to, a) clarify the project at a time when rework is less expensive, and b) reduce the risk of failure. Abandoning these practices increases your risk of budget, deadline or quality problems.

If you want to be Agile, a good place to start is to take basic life cycle phases, (such as requirements, prototype, design and test) and apply them to a small amount of work that takes between two and four weeks to complete. If you are contemplating becoming full-Agile, add the remaining practices that build communication and tracking into the project. Agile does not mean skipping all known best practices; it means adopting smaller versions of existing practices, and ones defined by Agile.

2. My company is trying to use CMMI, and now it wants to consider Agile; what shall I do?

Almost all the practices in Agile map to CMMI practices, but Agile provides more implementation details.

For example:

• Project status reviews in CMMI can be implemented by the daily stand up meetings in Agile.

• Measuring project progress can be implemented by the sprint and backlog burndown charts.

• Basic requirements definition and ownership can be implemented by user stories and the role of the product owner.

• Effort and size estimation can be implemented by ideal time and story points.

However, not everything in CMMI is in Agile. Some of these additional practices can be implemented in an agile way. For example, simple version control can be implemented by adding a version number to an artifact and taking a picture of it. Other CMMI practices (such as configuration management, risk management, supplier selection, process auditing and skills assessment / training) are additional steps that can be taken to mature an organization.

For a detailed comparison of CMMI and Scrum, see
http://www.processgroup.com/pgpostmar09.pdf

* Wikipedia.

Neil is a Certified Scrum Master, Certified High-maturity CMMI Lead Appraiser and Six Sigma Green Belt. Mary is a Certified Scrum Master, certified High-maturity CMMI Lead Appraiser.

[Top of page]

---

Tidbit #3: Improving Your Service Delivery with CMMI® for Services* - Quick Look

In February 2009 the Software Engineering Institute released CMMI for Services v1.2 (CMMI-SVC). The new CMMI-SVC model is a collection of practices aimed at service providers. This model is a companion to the original (and still current) CMMI-for-development model (CMMI-DEV) which is intended for engineering groups that develop products and systems. Examples of service organizations that can use CMMI-SVC are:

• Logistics
• Maintenance
• Human resources
• Health care
• IT services
  
  

When and why to use CMMI-SVC?
The purpose of using any framework is to improve the performance of an organization. For a group that provides services, this can include: reducing the amount of errors in services provided, reducing the labor needed to provide each service, improving consistency of service delivery, reducing the risk of mistakes and surprises, and maintaining the gains made over time.

A summary of the CMMI-SVC model is provided below. The items marked "(svc)" in red are the major changes compared to the CMMI-DEV model.

Summary of CMMI-SVC and changes compared to CMMI-DEV
At Maturity Level 2, a new Process Area has been added that contains the basic steps for service delivery. At Maturity Level 3 the engineering practices of CMMI-DEV (that were used to define and build components) have been replaced by practices to define and build services.

CMMI® for Services, Version 1.2

The new Process Areas are summarized below.

Service Delivery: The purpose of Service Delivery (SD) is to deliver services in accordance with service agreements.

Capacity and Availability Management: The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and ensure that resources are provided and used effectively to support service requirements.

Incident Resolution and Prevention: The purpose of Incident Resolution and Prevention (IRP) is to ensure timely and effective resolution of service incidents and prevention of service incidents as appropriate.

Service System Transition: The purpose of Service System Transition (SST) is to deploy new or significantly changed service system components while managing their effect on ongoing service delivery.

Service Continuity: The purpose of Service Continuity (SCON) is to establish and maintain plans to ensure continuity of services during and following any significant disruption of normal operations.

Service System Development: The purpose of Service System Development (SSD) is to analyze, design, develop, integrate, verify, and validate service systems, including service system components, to satisfy existing or anticipated service agreements. [This is an optional Process Area.]

Strategic Service Management: The purpose of Strategic Service Management (STSM) is to establish and maintain standard services in concert with strategic needs and plans.

Neil Potter is trained and certified to teach the services class and conduct appraisals.

* Information source = CMMI® for Services, Version 1.2,
http://www.sei.cmu.edu/cmmi/tools/svc/download.cfm

® CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

[Top of page]

---

Tidbit #4: Measuring a Process

If your organization is using defined processes for project and organizational tasks, you might be ready for some measures to objectively see how well they are being implemented. Measurement data can help an organization identify strengths, weaknesses and provide historical data for future planning. In this article, we give example measures for some common processes used within a project.

If you are using CMMI and implementing Generic Practice 3.2*, the ideas listed below are examples of what could be measured to obtain insight into specific process implementations. Tailor these examples to fit your needs or use them as a starting point to generate your own measurements.

In the examples, the term Earned Value is used. Some organizations use Earned Value Management to track project work. Each project task is assigned a value, and when that task is complete, the project records that value to indicate how much of the total project is complete. When process steps such as design, verification, risk and project tracking are included in a project's schedule, the completion of these steps is reflected in the total earned value for the project. When these process steps are skipped, or become stalled, the EVM system reflects these problems.

[Definition: # = Number of]

Requirements Management
Planned/actual effort/schedule to perform the process
# Requirements, growth, volatility over time
# Non-compliances for this process

Project Planning and Management
Planned/actual effort/schedule to perform the process
Final Earned Value number (Cost Performance Index, Schedule Performance Index) or planned vs. actual data showing how well planning and tracking went
# Non-compliances for this process

Risk Management
Planned/actual effort/schedule to perform the process
# Risks over time (increasing or decreasing)
# Risks realized or averted due to risk management
# Risks open vs. closed
# Non-compliances for this process

Configuration Management
Planned/actual effort/schedule to perform the process
# CM-related defects
# Percentage of bad builds
# Non-compliances for this process

Process and Product Assurance
Planned/actual effort/schedule to perform the process
Earned Value of the process assurance activities (i.e., whether all assurance activities were performed, and whether they were under/over budget)
# Requests for help vs. #unfrequented (or scheduled) audits (indicating how sought after the Quality Assurance group is)
# Non-compliances for this process

Measurement and Analysis
Planned/actual effort/schedule to perform the process
# Measures collected but unused
# Non-compliances for this process

Requirements Development
Planned/actual effort/schedule to perform the process
# Derived requirements (indicating the amount of initial ambiguity/completeness)
# Requirements, growth, volatility over time
# Defects in requirements documents, or defect density
# Non-compliances for this process

Design and Implementation
Planned/actual effort/schedule to perform the process
# Defects in design and code/drawings, or defect density
# Output over time (e.g., code/changes/design per engineer-week)
# Non-compliances for this process

Product Integration
Planned/actual effort/schedule to perform the process
# Defects found or defect density
Build audit results (e.g., #bad builds)
# Non-compliances for this process

Verification
Planned/actual effort/schedule to perform the process
# Defects found in verification or defect density
# Non-compliances for this process

Validation
Planned/actual effort/schedule to perform the process
# Test cases
# Defects found in validation, defect density, or test pass/fail percentage
# Actual test cycles vs. planned
# Rate of defect find vs. defect resolution
# Non-compliances for this process

Decision Analysis and Resolution
Planned/Actual Effort to perform the process
Earned Value for DAR tasks
# DARs performed per project
# Non-compliances for this process

Process Improvement
Planned/actual effort/schedule to perform the process
Earned Value for improvement tasks
Adoption of processes over time (e.g., #processes or practices used, measured via a mini-assessment)
# Defects found in process assets
# Non-compliances for this process

Training
Planned/actual effort/schedule to perform the process
# Training hours planned vs. received
Training evaluation scores
# Non-compliances for this process

* CMMI® for Development, v1.2, CMU/SEI-2006-TR-008, pp 89,
http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf

[Thanks to Ed, Bruce, Pat, Christof, Michael and John for the review.]

[Top of page]

---

Tidbit #5: Where do you Spend Your Time – Fulfillment or Demand?

Over the years, numerous time management models have been developed to help categorize and improve time allocation. Usually these models group activities by separating urgent and important initiatives from less pressing obligations.

An example of a time management model is provided in Figure 1. With this framework, all activities are categorized based on how important and urgent they are. The goal is to spend the majority of one’s time in quadrants I or II, and spend as little as possible on less important activities in quadrants III and IV.

 

Figure 1. Adapted from “The 7 Habits of Highly Effective People,” Stephen R. Covey, Free Press

The difference between the activities in Quadrant I and Quadrant II is that the activities in Quadrant I have urgent deadlines, and there is no room for errors or delays. The same work can be performed in Quadrant II, but it is planned to avoid extreme and chronic urgency. Quadrant II also includes improvement and preventative actions that reduce the overall volume of work in Quadrant I.

Individuals and teams that over-commit or make numerous errors tend to spend a lot of time in Quadrant I trying to catch up. While activities in this quadrant can produce growth and success, too much time spent here will only increase the volume of work in Quadrant I. For example, a deliverable that is rushed out full of mistakes will lead to a list of urgent repairs. If those repairs are rushed, more urgent repairs will result.

A good target is for 40-70% of activities to be in quadrant II. If you are spending more than 75% of your time on urgent items, you add excessive stress to your efforts and only increase the volume of Quadrant I work.

One might recognize that certain aspects of their life occupy each of the quadrants. Still, how much time do you spend in Quadrant II? The premise is that the more you spend on these activities, the more you can achieve with less stress. Quadrant I should not be empty since this is where the demand on you can cause growth.

Here are some examples of Quadrant II activities. When reading through them, identify some actions you can take.

• Perform tasks well in advance of deadlines.

• Estimate and plan work before committing in order to avoid being chronically over-committed.

• For each crisis (Quadrant I), take steps to prevent future problems:
  • Identify similar errors (or trend) when a single significant error is found in a piece of work.
  • Plan ahead for the next major event, especially if a similar event does not go well.
  • Create and update a checklist so that when an important task is forgotten there is a visible reminder.

• Schedule improvement activities
  • Attend classes and seek a mentor.
  • Conduct team-building activities.
  • Assess and implement lessons learned.
  • Complete one small part of the project from beginning to end and apply the lessons to the remaining work.

• For important and recurring activities, determine whether such efforts can be accomplished faster or more effectively:
  • Eliminate steps that do not impact the desired end result or add risk to the success of the activity.
  • Automate common tasks (e.g., collection, storing, reporting and sharing of project data).
  • Use a common organizational structure and format for project data when individuals frequently move between projects.
  • Avoid manual note-taking which requires later transcription. Always use a PC to collect minutes and actions with a common sharing mechanism (shared web page or database).

Figure 2 provides a similar model to Figure 1; however, here the categories include additional names and are grouped in the graphical layout of an archery target to remind us where to focus.

Figure 2 – “Time Targets,” adapted from The Time of Your Life, by Anthony Robbins

Whichever representation you prefer, it is important that it be used to identify where time is spent now and to determine which actions you can take to shift your focus. In the end, one needs to be patient and make improvements incrementally and consistently.

[Top of page]

---

 

Tidbit #6: Project Planning and Monitoring & Control for a Services Organization

The CMMI services model consists of Process Areas (PA) to help service organizations improve their performance and consistency. Much of the discussion in the CMMI community, and in available training, is focused on the new service-specific PAs rather than the core PAs pulled in from the development model (such as Requirements Management, Project Planning and Project Monitoring & Control). In this, and later tidbit articles, we will discuss some of these core PAs and how they can be used in a services group. This article will focus on Project Planning (PP) and Project Monitoring and Control (PMC).

The first thing to note is that PP and PMC are applied to the operation of a services group, not each service request. The Service Delivery PA handles individual service requests, leaving PP and PMC to handle the overall planning of the group, in addition to unusual special requests. This is a departure from the development model, where PP is applied to each development request (or group of requests).

To explain the goals of PP and PMC, we will take an example of a financial services group. The group:

• consists of 15 people.
• tracks the costs of 5-6 large projects at any one time.
• has been providing project cost and budget tracking services for their division for many years.
• is not planning on adding any new services in the next calendar year.
• has been requested to upgrade to a new tool and new financial process for tracking the cost of all company projects.

 

In Table 1 we list the Specific Goals (SG) and Generic Goals (GG) of the process areas and the group’s implementation of them.

Process Area Goal	Example Implementation
PP SG1: Estimates of project planning parameters are established and maintained.	A roles and responsibilities document states the overall strategy and typical tasks performed when providing financial services on each project. Additional common tasks are defined by government regulatory financial procedures. The effort needed to support all projects for the fiscal year is estimated, based on the number of projects, the complexity of each project and the financial services required. The tasks for non-standard work are developed, budgeted and tracked. Examples of non-standard work are: moving data to a new tool, incorporating new procedures into the department, and adapting services to deal with new types of projects.
PP SG2: A project plan is established and maintained as the basis for managing the project.	A specific schedule of financial reports is created for each project. The schedule consists of milestones for financial reporting, task assignments and the budget (effort and costs) required. Risks are assessed for the department as a whole, looking at new tool, reporting and staffing risks. All of the artifacts generated by the group (e.g., agreements and financial reports) are stored in pre-defined directories with pre-defined names and read/write access, backed up each day on an off-site server. A plan is created for the department at the beginning of the fiscal year describing the overall workload, resources, stakeholders and budget. For each project that the department provides financial services, there is an approved service level agreement for the duration of the project. Each staff member has a training plan that includes any new skills for financial reporting (e.g., learning new tools, new financial reporting requirements and overall career development).
PP SG3: Commitments to the project plan are established and maintained.	The department plan is approved annually and adjusted monthly and covers all department activities. Specific service commitments are defined in service agreements with each project. These are approved before financial tracking starts.
PP GG2: The process is institutionalized as a managed process.	There is a corporate policy that states what annual fiscal planning and tracking activities are needed for the department and the financial planning activities needed for each project. These activities are tracked in the annual fiscal planning review and when each project starts up. Senior managers receive an orientation on fiscal planning activities for the department.  All staff members receive planning training related to the activities they perform.
PMC SG1: Actual performance and progress of the project are monitored against the project plan.	The hours expended across the department to provide services are tracked monthly. When the complexity and size of a project changes, effort estimates to provide the financial services to the project are revised. The commitments in the financial reporting schedule are tracked, and any changes in stakeholders are incorporated. Weekly team meetings verify overall status of financial tracking activities across the department. There are specific milestones on each project where financial reporting and progress are evaluated.
PMC SG2: Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.	All action items and issues are tracked in meeting minutes and closed in subsequent reviews.
PMC GG2: The process is institutionalized as a managed process.	There is a corporate policy that states what annual fiscal tracking activities are needed for the department. This covers resource and cost expenditures, and approvals for changes. Senior managers receive an orientation on fiscal planning/tracking activities for the department.  All staff members receive training in tracking the hours expended on the activities they perform.

Table 1 – Example Implementation of PP and PMC Goals

Summary

These two process areas are not worded conveniently for service organizations, so translation is required. However, after translation, PP and PMC are useful process areas to verify that a services group estimates and tracks operational items such as effort, tasks, milestones, risks and budget. Performing the practices of PP and PMC ensures that a group can consistently meet its service delivery expectations.

[Top of page]

---

Questions, comments? Contact us.