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

 

Advertisements

CMMi – Project Plan – Introduction

Project Planning

Heard of this…hah! you got to be kidding me Amit, you seems to have lost your senses…this is what we do daily, we talk about this delay, we always say that our project is getting delayed…we are missing deadlines…we are not on track…. :), we do have a plan dude! I see many of you thinking aloud this in your mind…well good for you…now go back and read the same lines again…one more time…

we talk about this delay, we always say that our project is getting delayed…we are missing deadlines…we are not on track…

And you say you have a project plan, and you talk about this daily…now is my turn to say…YOU must be kidding me! How can you ever have a delay in your project, how can you ever miss a deadline…IF you ever had a Project Plan!!!! Have it in your face…I am loving this giving you back…

From today let’s make things a bit “Real”…let me introduce Rehan as a character in this journey, and Rehan…he will be a project manager in our organization…so what does Rehan do…, tell us Rehan!

Well Hi, I am a project manager, and I should be managing the project…OK, sounds good…why is that I am made a project manager….? Well, I did good in one project, I am out spoken…my boss feels I can be good in client communication, and well, I speak a bit of jargons!

So???

Does that make you a good project manager…hold on…we are diverting, our job is to understand Project Planning and not to determine my worth of being a project manager…

All right…perfect, so lets start with asking few questions from Rehan!

What is a Project Plan…Mr. Rehan?

Ha!..this is a plan for the project, in which we have everything…

Can you be more specific?

Well…I mean…OK, if you feel you’re so good, tell me what is Project Plan?

With Pleasure Mr. Project Manager!

A project plan is a formal, approved document which is used to manage and control the execution of the project.

It is based on project requirements and established estimates.

The project plan should consider all phases of the project lifecycle.

Oh! Yes, now I know…hmmm… this is exactly what I meant…just that not coming out! You know…its been a while, I am more of a practical guy!

Ah…practical guy…right…ok…tell me about this…

Do you:

  1. Establish the Budget and Schedule?
  2. Identify the Projects?
  3. Plan for Data Management?
  4. Plan for resourcing?
  5. Plan for Knowledge transition / Training?
  6. Plan for a Project Plan?

So, Mr. Practical Project Manager?

See, this is what happens, when we think we do…but in reality we are far away from doing! And this is where we want all of us to understand and be on the same page!

In tomorrow’s post, will go through these topics in detail and we will also see, what are the work products associated with Project Planning!

Till then…Cheers!

CMMi – Project Planning

From today onwards, we will see what are Process areas (Like Project Planning, Requirement Management etc.) and how we are going to get these implemented with in our Organization.

Let’s understand this:

At maturity level 2, the projects have

  • ensured that processes are planned and executed in accordance with policy;
  • the projects employ skilled people who have adequate resources to produce controlled outputs;
  • involve relevant stakeholders;
  • been monitored, controlled, and reviewed;
  • been evaluated for adherence to their process descriptions.

This is very important to understand that Maturity level 3 contains all the elements of Maturity level 2 and additional for level 3.

Now as we understand the maturity level 2 have got defined policies, resources, stakeholders, and evaluation procedure. This is so very cool…so far…

Also at maturity level 2, the status of the work products (Example will be Requirement documents, Functional Specs time sheets etc.) are visible to management at defined points (e.g., at major milestones , at the completion of major tasks).

Product

—A work product that is intended for delivery to a customer or end user. The form of a product can vary in different contexts. (See also “customer,” “product component,” “service,” and “work product.”)

Work product

—A useful result of a process. This can include files, documents, products, parts of a product, services, process descriptions, specifications, and invoices. A key distinction between a work product and a product component is that a work product is not necessarily part of the product.
We intentionally are not following a step by step “Alphabetical flow” to understand all this. Best is to start with what we do daily in our life, that is planning. Most of us have been involved in Project Planning and associated activities with this, so let’s talk about the same:

But before we do, let’s see what all is contained within the project planning process i.e. PP as a process area:

Project Planning

Project Planning

Now while you are looking at this, let us explain a bit about the terminology:

SG: Specific Goals

SP: Special Practices

All rightie so all set! I am…Let’s get started….My first question to all of you:

How is WBS (Work Breakdown Structure) established.

How are changes to this are controlled.

How is it used?

Cheers 🙂

CMMi – Capability Model

All right…with understanding of what CMMi is all about, what do we mean by maturity levels, and how we can actually map the maturity levels with the process areas, we are all set to learn about Capabilities, the maturities and capabilities have a great role to play in the entire CMMi journey.

In CMMI models, there are six capability levels designated by the numbers 0 through 5.

  • 0 – Incomplete
  • 1 – Performed
  • 2 – Managed
  • 3 – Defined
  • 4 – Quantitatively Managed
  • 5 – Optimizing

So I am sure you all will be in better control of things even as you have a look at the above mentioned “Capabilities”.

Let’s understand as to what they mean, we will start with very small description of these:

Level 0: Incomplete

An “incomplete process” is a process that is either not performed or partially performed. One or more of the specific goals of the process area are not satisfied and no generic goals exist for this level since there is no reason to institutionalize a partially performed process.

By Institutionalize we mean a process which is tailored as per Organization needs, and is stemmed out of your Organizational processes.

Level 1: Performed

A Capability Level 1 process is a process that is expected to perform all of the Capability Level 1 specific and generic practices. Performance may not be stable and may not meet specific objectives such as quality, cost, and schedule, but useful work can be done. It means that you are doing something but you cannot prove that it is really working for you. This is what that happens with quite a few project which you’ll or we have worked with! We know we are doing something, and that is why we are being survived, but that has nothing to do in terms of improving our cost. and quality.

Capability Level 2: Managed

A managed process is planned, performed, monitored, and controlled for individual projects, groups, or stand-alone processes to achieve a given purpose. Managing the process achieves cost, schedule, and quality. As the title of this level indicates, you are actively managing the way things are done in your organization. You follow metrics, you follow things like variance, scheduled variance etc., to make sure you and your project is on track.

Capability Level 3: Defined

A capability level 3 process is characterized as a “defined process.” A defined process is a managed (capability level 2) process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines, and contributes work products, measures, and other process-improvement information to the organizational process assets.

Again, I won’t go in to details of level 4, and level 5, so this is it for today, assuming you all are having a good go and learning experience in this journey!