CMMi | Project Delivery Approach, Mission Possible!

In this blog post we will discuss about the ‘Project Delivery Approach’, how we should make sure to deliver a project successfully to clients.

CMMi has its unique way of getting things done, and in Organizations, the smaller one on that…it becomes extremely difficult for people to understand and realize the importance of following process. So How do we do it?

Well, you got to make things easy for them. you have to make sure that it becomes part of their daily routine, without even making a change in what they have been doing. Believe me, in smaller Organization the work load a resource go through is massive, and hence asking them to fill in the CMMi docs, following deadlines, and deliver project on time…makes CMMi a absolutely No-No on their part.

Today we will talk about the Project Delivery Approach. This is a document which sums up the activity that every project should be doing, including what type of artifacts are required, and where to keep them! :)…yes, we’re going to unravel the mystery behind CMMi….Let’s get started!


This document describes the project and  summarizes the project delivery approach.  It is owned by the offshore Project Manager.  The objective is to describe the overall structure and control mechanisms used to govern the project at offshore.

Whether it is an Onsite-Offshore delivery model, or is completely Offshore delivery approach, this document takes care of every aspect involved in delivery

Once we are clear with the objective of the document,next comes is Client Overview.

Client Overview:

This is the place where you define a brief note about the client. The idea is to understand which client this document is going to be about, and what client business is.

Remember this document is not ONLY for the person who is going to make it, this makes round across the Organization in various departments! Hence every effort should be made to make sure it is easily understood, and communicate the language which is well understood with-in Organization.

In the next series we will go on and talk about remaining sections of PDA.

Technical Specification – CMMi

After having discussed in detail about the Requirement Development and Management, we are going to start with Technical Solution. But before we start with that, we would need to understand few terms:

What is Specification?

  • A software requirements specification (SRS) is a technical requirement document that describes in detail the externally visible characteristics of a software.
  • A SRS is not the same as a statement of user needs OR ‘Requirement docs’. The SRS says what the product will be.
  • The SRS can include Plain English text, structured text, diagrams, tables,rules, etc.
  • Parts of the SRS include:
    • Environmental requirements: OS, platform, interoperability, standards, etc.
    • Non-functional requirements: security, usability, efficiency, etc.
    • Feature specifications: precisely describe each feature
    • Use cases: examples of how a user accomplishes a goal by using one or more features

What is Design?

  • A design document explains the implementation that will satisfy the requirements of the SRS.
  • There are many aspects of the system that you need to design:
    • Division of the system into components
    • APIs and dependencies between components
    • Classes, attributes. operations, and relationships within each component
    • Data representation in the database or even files
    • Key algorithms and conditions that affect the overall design
  • Many notations are used in design
    • Plain English or structured English
    • Many types of UML diagrams
    • Pseudo-code, other diagrams as needed

What is the Difference Between SRS and Design?

  • The SRS describes precisely what the system will do.
    • It is based on customer needs
    • It defines stages for design and system testing
  • Customers should be able to review SRS and help validate it.
    • Validation of requirements means checking the written requirements against reality!
  • Design outlines how the system will work.
    • It is based on the SRS
    • It sets the stage for implementation as well as integration testing
  • Usually development team needs to review the design.

What Do They Have in Common?

  • Both SRS and Technical Design documents are technical documents that need to be precise.
    • At times the same notation is used for multiple purposes
  • Both need to be reviewed by stakeholders and defects must be corrected.

What Makes a Good Specification?

  • The 4-C’s of requirements states:
    • Clear: It should be understandable so that all stakeholders can participate in validation and developers know what to build and test
    • Concise: Short requirements are more understandable and maintainable. And, they often are more precise
    • Correct: Incorrect requirements will lead to major rework and reduced revenue.
    • Complete: Incomplete requirements also leads to major rework and last-minute schedule changes.
  • The specification should not bias the design or implementation.
    • Don’t get ahead of yourself, you will do design later, this is very important, and make sure you understand this!
    • Design details can make the SRS harder for non-technical stakeholders to understand
    • You may come up with better ideas for the design later but you should NEVER change the SRS unless your goals for the product change.

Requirement Development – Iterative Model

What is Requirement Specification? What is Software Requirement? What is requirement Engineering?
Before we answer these questions on Requirement Management, and requirement Specifications, let’s talk about the following!
  1. A process is a description of how to accomplish a work activity
  2. A procedure is a set of steps for accomplishing the work tasks of a process
  3. A technique is the way an individual accomplishes a procedure

This is it that we have in Software development. How can you be a brilliant Software Developer! Ah, Amit, C’mon, you must have had lost your senses! We’re good developers / Testers, and Project managers!

Do you really think so, if you do, let me know how many items out of the mentioned below you follow while doing development!

  • Do you follow coding style guidelines
  • Do you follow code documentation guidelines
  • Do you really use debugging tools
  • Have you ever done your code being peer reviewed
  • Do you even know about testing strategies, procedures, and tools
  • Do you even know what periodic backups are
  • What isa version control system
  • Do you know how to use a defect tracking system
  • What isa design documentation tool
  • What is with requirements traceability tool
  • What do you know about project planning and tracking system

I bet most of you developing the code (and no offence here), would know at max about 2 or 3 of these. Reason, well primarily you don’t think that it is necessary OR it’s not your responsibility! Whatever is your reason, of you’re not following all the above you would surely be successful in your career BUT only in very short run!

Now here is a thing which we all should be aware of. Your project may follow the ‘Waterfall’ approach, BUT it is not necessary that during the requirement gathering phase too you have to follow the same model. You can always and in fact should always utilize various approaches for doing various activities of SDLC.

Here is how you should do Requirement Development using Iterative approach.

Requirement in an Iterative way!

Requirement in an Iterative way!

Now let’s talk about the Process flow for Requirement Development.

Why is it that my entire focus is on Requirement Analysis and not on other aspects of SDLC. Think about it! Majority of the time project failure is because of Improper Requirement Gathering—Yes, believe me, this is from experience!

Any available Software Projects workflow will have varied components, and requirement development is one of them.

Requirement Analysis Work Flow

Requirement Analysis Work Flow

Below mentioned is the COMPLETE detail on how Requirement should be done, following the requirement iteration flow!

Requirement Analysis - How

Requirement Analysis - How

Did I ever tell you what Requirement actually is?


Requirement is : The external (user) view of the system
                                                                              Which Includes
Functional requirements (what must the system do?)

                                                                              Which are

Prioritized as Essential, Desirable, Optional

and prioritized within categories, which also has

Quality attributes (how well must the system do it?)

                                                                              Which Includes
Safety, security, reliability, performance, throughput, capacities

Can also be prioritized
– e.g., security versus performance
• Usually apply to multiple (perhaps all) elements of the system
• Each operational requirement is tagged as “valid” or “design goal”

Simple isn’t it…Cheers! We will start with Project Planning Tomorrow!

Project Management Cycle – via pics!

Let’s learn Project Management easy way!

We have been talking a lot of stuff which was more ‘Textual’ in nature, and today let’s respect ‘A picture is more than thousand words’ – the phrase!

Now let’s see as to how each and every element is so very important for us. This way you’ll be able to align this with CMMi. And that is an essence to learning CMMi.

CMMi Supporting Process

CMMi - Supporting processes

By the way we have been discussing about processes! What exactly is Process?

There are three key factors in software engineering:

  1. People: numbers, skills, morale
  2. Process: This is a procedure for doing the work
  3. Technology: This is characterized by platform and domain

Good processes help people apply technology
Efficiently: without wasting time, effort, or
and Effectively: while obtaining the desired

What is a Process?

A process is a systematic way of doing things:

Systematic means any action which is teachable & repeatable

A model associated with a process specifies:

  • the work activities to be accomplished
  • interconnections among the work activities
  • the input work products on which work activities are based
  • the output work products produced by work activities
Waterfall Model

Waterfall Model


We will talk about these in detail, but today, please make sure to understand every aspect of each and every image attached here:

Engineering Processes

Engineering Processes


Bi-Directional Traceability Matrix – CMMi

What is Requirement Tracebility Matrix?
Today Let’s talk about the requirements traceability matrix in a bit detail? Please realize that traceability matrix is among the few very important component associated with CMMi process areas.

What is Vertical and Horizontal Requirement Tracebility Matrix?

Requirements traceability is the ability to relate your requirements with one another and with aspects of other project artifacts. The primary goal for RTM is to ensure that all of the requirements identified by your stakeholders have been met and validated.

Building a System Out of its Requirements - Dy...

Image via Wikipedia

I personally feel that RTM is a great idea in quite a few situations.

Image via Wikipedia

There are two types of Traceability Matrix:

  • Vertical traceability is an aspect which identifies the origin of requirements (for example, customer needs) and follows these requirements as they evolve through your project artifacts, typically from requirements to design, to the source code with the help of which you implement the design, and then the test cases / test plan that validate the requirements.
  • Horizontal traceability identifies relationships among similar items, such as between requirements itself. This enables us to anticipate major problems, such as assuming two subteams implementing the same requirement in two different components. To understand this better,lets take a very easy example for creating a ‘Single-Sign-On’ functionality. the requirement here remains similar but you implement it across various platforms.Hence a traceability is often maintained bidirectionally: You should be able to trace from your requirements to your tests and from your tests back to your requirements.
In short and simple words if a requirement or any work product changes and it will affect some other work product, potentially affecting the value you deliver, then it’s probably something that should be part of requirement traceability matrix.

How do they do it – Requirement Management – CMMi

All right, so this is it for learning, and now is the time for all of us to understand and see the implementation in real world.

The theme is based on ‘How do you do it’?

Let’s get started, believe me this is going to be a fun ride and the knowledge you all will have by the end of 10 days goes beyond your imagination!

Requirement Management:

<<This comes under Basic & Advanced Maturity>>

Whenever you sit for the requirement management, make sure to follow the below mentioned rules:

Problem you should solve – Requirements are managed and inconsistencies with project plans and work products are identified!

Objective should be – Your objective here is to explicitly ask your requirement owners about the meaning of each and every requirement they come up with!

Please describe how project personnel develop and understanding of the requirement? Do you also interact with requirement providers?

And the evidence you need to support this would be:

  • Statement of Work
  • System & Software Requirements Specification (SRS)
  • Business & User Requirements Specification
  • Use Cases
  • Minutes of meetings

    Good to provide

  • Acceptance criteria as part of SoW
  • Review and approval records of SoW
  • Requirement Reviews
  • Approval of SRS/Use cases

Problem you should solve – Obtain commitment to the requirements from the project participants!

Objective should be – You should surely have the documented evidence!

How do you obtain the commitments to the requirements from the resources associated with projects? Do you review / approve the requirements?

And the evidence you need to support this would be:

  • Project plan with resources allocated
  • System & Software Requirements Specification (SRS)
  • Business & User Requirements Specification
  • Requirements change request logs, with commitment (e.g., emails) and estimates of impact (e.g: functionality impact, interface impact, design impact, validation impact etc…).

    Good to provide

  • Project Kick off MoM
  • Requirements Review and approval Records
  • Minutes of meeting
  • Effort estimation Reports

How the changes to the requirements are managed? Whenever a change happens how do you manage that change? How do you assess the changes?

You should have the answer with following artefacts

  • Change Request
  • Evidence of Project Plan Update
  • System & Software Requirements Specification (SRS) / Revision History of SRS
  • Review records of SRS, Use Cases
  • Requirements Traceability Matrix (RTM).
  • Revisions to work products resulting from changed requirements.

    Good to provide

  • Project Kick off MoM
  • Requirements Review and approval Records
  • Minutes of meeting
  • Effort estimation Reports

Much of requirements management is change management. Tracking the status of project change requests is an eye-opener: how many of them are open and how many closed? How many requests were approved and how many rejected? How much effort was spent implementing each approved change?

You should have answer of all these, and the above mentioned document should give you proper answers on these.

How do you maintain the traceability between your requirements, plan, and work products?

You should have the answer with following artefacts

  • Requirements Traceability Matrix (RTM) / Both Horizontal & Vertical traceability
  • System & Software Requirements Specification (SRS)
  • Checklist associated with RTM

    Good to provide

  • Email exchanges related to RTM review
  • SQA Audit/Internal Audit reports containing issues related to traceability among requirements
  • RTM Review Records

How do you identify the inconsistency between the project plan and the requirements that you have identified?

You should have the answer with following artifacts

  • Review and approval records of project plan and its associated plans
  • Documentation which identifies that there is inconsistency between the project plan / work product / requirements.
  • CR against the requirements
  • CCB meeting which identifies that this change has a resource available.

    Good to provide

  • Email exchanges related to RTM review
  • SQA Audit / Internal audit reports
  • RTM Review Records

This should be good for now…will come up with another process area which will be RD tomorrow 🙂 Cheers!

CMMi – Requirement Development Part – II

With having answers of two very important questions on Requirement developments, lets get in to more detail, and understand how how to establish the product and product component requirements?

So my question to you would be:

What products do you deliver to customer? How do you establish these requirements?

The CMMi says “Establish and maintain product and product component requirements, which are based on the customer requirements”

Let’s understand as to what this mean, this is so critical that you may eventually end up getting surprised as to how detail a CMMi process can be when we talk about use of ‘specific’ words!

Now have a look at ‘Establish and maintain product and product component requirements”, now your question would be:

Well Amit, you know, Product Requirements are when we have documented the customer needs and I have performed the next step, interpreting and writing the technical requirements in three categories, which are mainly functional, non functional, interface…so what the hell is this product component requirement?

This is going to be a long post so bear with me, as this is the essence of entire project planning, if you master this aspect, we are good with any complexity of project!

Product Component:  In the CMMI Product Suite, a work product is a lower level component of the product. Product components are integrated to produce the product. There may be multiple levels of product components. I’m sure you all understand this, there is an example to follow this.

Product Component Requirements – The complete specification of a product component, including Look and feel, form, function, performance, and any other requirement.

Building a System Out of its Requirements - Dy...

Image via Wikipedia

Most of you must be having a smartphone…yeah, not like me, who is still with 1100 Nokia ;)…so, a smartphone as a product have got various product components, like the screen, the keypad, the battery, the AMOLED screen, well there are other too, but these one will do for this discussion!

Now each and every ‘Product component’ has got associated ‘Requirements’ which we call as ‘Product component requirements’

Now whenever you talk about a project, let’s take an example where in you have to come up with an eCommerce website, this website as a product, can be broken down in to one or more components. And then it is also possible to break down these components in to further sub-components.

I hope you have a clear understanding of product requirements and product component requirements..perfect!

Remember this is very important to have detailed quality requirement at this stage, the example can be:

  • Respond with in 1 second
  • System is available 99 % of time
  • Implement a change with no more than one staff week of effort
You need an SRS (System Requirement Specification) at this stage.

There is one important aspect in the RD process which talks about maintaining the ‘bidirectional traceability’, we will talk about that later.

Now very important question that comes up now is:

What components of the products are identified? How do you allocate the product requirement to components?

The intent of this practice is to make sure that the requirements for each product component (Remember AMOLED screens, battery etc.) are correctly specified (allocated).

You are still not in implementation mode, you’re only trying to make sure that requirements are properly allocated to their respective components.

So here at the product component level, you may have a mix of hardware requirements, software requirements, performance requirements, operational requirements, etc. The basic idea about requirement development at this stage is to allocate these different requirements to their respective components so you don’t implement a software requirement in to say operational or the other way round! 🙂

You need an RTM (Requirement Traceability Matrix) at this stage.

CMMi – Process Area – Requirement Development – Part I

Well, this is going to be an exciting journey from today onward. Lot of real life examples, scenarios, and meeting inputs from behind those closed doors.

We’re going to talk about Requirement Definition in detail, and we will try and understand the importance of the RD process area as to how this effects our project and project planning. Everything is oriented towards one goal and that is ‘Deliverable’.

From now on you’ll have one liners like these, which may not have any sync to the topic being talked about but for sure is going to make it easy for you to remember!

Risk and contingency is the part of Project Management process during developing project on which is concerned.

So lets get started:

RD process area explains three types of requirements, and they will be customer requirements, product requirements, and product component requirements.

The two very important thing about any project is to make sure that they address the needs pertinent to different phases of life cycle, and at the same time they take care if various attributes of the project like reliability, and responsiveness to name two).

When we say ‘Development of Requirement’ that actually means the following:

  1. We are eliciting, analyzing, validating and communicating the customer needs so that we can get a prioritized list of customer requirements, which constitute an understanding of what will satisfy stakeholders!
  2. We develop the requirements for the entire life cycle of the project
  3. We define the functional and quality requirements for the customer / client.

The focus is on to identify not only the product level requirements but also the specific design level requirements too.

So the very first question that we should have answer of:

How would you identify and collect your stakeholder’s needs, expectations, and constraints?

While doing requirement gathering the following objectives should be kept in mind:

Requirements Elicitation should talk about:
1. The problem associated with Scope.
2. The problems regarding understanding the complete requirements
3. The problems associated with the change (volatility) of requirement.

There can be various ways where by you can identify and collect the requirements, few of them are as:

  • Use cases
  • Business case analysis
  • Brainstorming

And from the artifacts perspective, please make sure you’ve the following: Use cases, presentations, documents, clarification logs, issue logs etc.

Now comes the other question, which will be

How do you transform the stakeholder’s need in to customer requirements?

Now once you have gathered the requirements or needs from customer, then next step is to come up with a business requirement document.

The steps involved during this stage should include the following:

  • Consolidate the various inputs from the stakeholders
  • Obtain the missing information
  • Resolve the conflicts while documenting the recognized set of customer requirements.

Never forget that there is often more to customer requirements than just “how the product should function” and those requirements also need to be elicited.

For example, a customer might “Require” that your product should be installed in their own network environment and validated there before it goes to full production system.

On the other hand, another customer might “Require” that you validate the product in a test environment that fully matches their own environment – that puts a lot of requirements on your test environment and architecture needs.

The verification and validation of customer requirements might include what customer data has to be used – and this can impact data management strategy as well as your test environment and architecture. Or this can also happen where in customer might not be willing to provide “real” data due to security issues, and then you would have to come up with a way to create, load, and manage enough data for testing purposes.

This is quite significant from planning and strategy perspective. All these details should go in to BRD, FSD, and clarification logs.

One of the most important thing that you will know once we move ahead is:

  1. You should create a requirements baseline that does not change unless there is an approved change request.
  2. Investigate, Impact, and Review all proposed requirements changes with the relevant stakeholders (approved or rejected), and
  3. Only make approved changes to the baselined requirements and appropriately update the traceability


CMMi – Project Planning – Identify Risk

Risk: One of the most important component for any of the Project Planning related activities.

Does this scenario seem familiar : “Ah, you know what we planned that we will be able to create this webservice in a week’s time, and suddenly this the Dev is not available!” So? You planned for this…right, this is a risk? Yeah…Ummm…you know what, I didn’t…!!! What???

Well this must be familiar with many of us under various circumstances as we move ahead in our projects. Hence Identifying and analyzing the project risks is a massive opportunity for us as a project manager  to make sure that the deliverable are running on time. So, How do we do this?

Now this is where things gets slightly trickier as we move! The identification of risk involves following two aspects:

  • Monitoring the Risk (This is part of PMC – Project Monitoring and Control)
  • Risk Management (This is part of Risk Management – RSKM)
English: The diagram above represents a generi...

Image via Wikipedia

We will talk about these in near future, but for the sake of this discussion let’s talk about why Risk identification is necessary?

Risks are identified or discovered and analyzed to support project planning. Now this is an exercise which should take place across all plans that affect the project to ensure that there is an interface among all relevant stakeholders on identified risks.

Remember this : While doing project planning, the project plan is supported by various documents, and hence Identifying the Risk is a filler for Project Planning, which means that this filler itself has a procedure to be followed.

  1. We should identify the Risks.
  2. Analysis of the risk, and determination of the impact, probability of occurrence
  3. Giving priority to the risks

Let’s talk about how do we identify the risks:

Examples of risk identification and analysis tools may include the following:

  • Risk assessments
  • Checklists
  • Structured interviews
  • Brainstorming
  • Process, project, and performance models
  • Cost models
Here is the model associated with Risk Management:
CMMI Project Planning – Meta-data model

Image via Wikipedia

Once this is done, then we document the risk, and review and obtain the stakeholders approval and agreement.

Once you’re done with doing Risk identification, you should have answers to the following questions:

How are Risks identified and analyzed?

The answer for this should be:

Well, we have a list of identified risks, and we call this a risk watch list, a risk plan, which has got documented analysis of the risks, and very importantly we do have a Standard set of typical risks for specific type of  projects.

We will be talking about other aspects of Project Planning and probably by the end of this week you all should have better understanding of how to do Project Planning. Cheers!

Project Plan – How to Budget and Schedule!

Conflict engages. If people have no opinions, no objections and no emotions, it usually means they don’t care. And you’ll be hard-pressed getting their help when you have to actually implement your idea.

So, our Project Manager Rehan is having a very hard time in understanding the Project Plan, and he is a Project Manager, what an irony…well, this does happen with many of us, so lets go ahead and understand as to what all we need for “Estimating Budget and Schedule”

Any project has a defined and allocated budget and the associated schedule which are based on Estimates and it is the responsibility of the project manager to make sure that budget allocation, task complexity, and task dependencies are properly addressed. And how would Rehan do this, by Project Planning.

We are here looking for

  • Schedule of Project
  • Budget of Project
  • Schedule dependencies

You have to understand what are your major milestones. If any project includes a QA milestone, then the QA review is conducted to ensure that the assumptions and requirements associated with that milestone (Say the milestone was to complete writing of test cases) are being met or not!

You should definitely look out for assumptions made in the schedule.

Another very important aspect is to talk about Constraints, I mean the factors which limits your flexibility. Like resources, task duration, complexity, outputs!

Dependency on task is a massive contributor for projects getting delayed. We never anticipated that UI team will not be available, and we forget to include their time! Hell No!

For establishing and maintaining the project’s budget and schedule think on these lines:

  • You should define the availability of resources whether they are committed or expected
  • You should understand that work being done in phases give much better result, so provide timeline for activities
  • Break It! Essence of any task, you should provide the breakout of major schedules
  • I don’t like dependencies, leave this for any other day, while planning you got to define dependencies among activities!
  • How would you measure your project, the keyword is Milestones! Define them!
  • Identifying the milestones, and releases for the delivery of products to the customer
  • This is of massive importance, Provide appropriate time gap between defining milestones!
  • Documenting project assumptions and rationale

So this is all you need to think and understand before you decide on project budget and schedule! Next we will discuss about Risks!