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!

Objective:

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.

CMMi – Requirement Development Part – III

So, what next…well lot of things still left in requirement development, and I guess you are enjoying every bit of this.

After coming up and deciding on every requirement, the components, and associating requirement with product component next in line for us is:

Now we need to analyze and validate our requirement, which give us variety of other question to answer:

How are Operational concepts and scenarios developed and maintained?

This would mean: During the requirement development phase, you should come up with various scenarios, all these scenarios should be augmented with quality attributes.

A scenario is typically a sequence of events that may occur during the use of the product or project, which is used to make needs of the stakeholders as ‘Explicit’. An operational concept for a product usually depends on both the design solution and the scenario.

You need to have FSD (‘Functional Specification Document’) at this stage.

Requirement Development - Engineering

Requirement Development - Engineering

The next question that arise at this level is:

How you define the functional requirements?

Definition of functionality, which is also referred to as “functional analysis,” is the description of what the product is intended to do. In simple terms what do you mean by Functional analysis, which will term as the “Required” functionality of the project / product. The definition of functionality can include the actions, sequence of those actions, inputs required for those actions, outputs, or other information that communicates the manner in which the product will be used.

You need to have FSD (‘Functional Specification Document’) at this stage. <<To be specific you should focus on IDD (Interface description document), and ICD (Interface Control document) which are part of your FSD>>>

Once we have functional specification document, next question we should ask from ourselves is:

How do you analyze whether the requirements are necessary and sufficient?

At this stage we analyze the requirement. We look at the design and talk about feasibility from requirement perspective, or which requirement affects feasibility.

You need to have Requirement Defect Report at this stage, supported by peer reviews comments, proposed requirement changes which will eventually have a change log.

Once we have identified and analyzed the requirement, this is the time for asking few more questions:

How do you analyze whether the requirements balances the user needs and constraints?

Make sure you’ve result of all the conversation, and proof of records showing analysis and negotiations of tradeoffs between requirement, cost, and schedule etc.

And now the last but not the least question:

How do you validate the requirement that your product will meet the user’s needs?

Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation.

At this stage be ready with Design docs, Simulators, Analysis etc.

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 – Estimation

Talking of Project Management, we have always been told…that the project is or was failure due to project manager. I strongly disagree! And why do I do this, because, I know that project manager as individual are not the only reason for any project’s failure, this is more due to the lack of project management resources or you may call it process which results in a failure!

So starting from where we left yesterday, lets begin by understanding what all we have in Project Planning, and how the Project planning combines with requirement management, project maintenance and control etc.

Basic Project Management Process Area

Basic Project Management Process Area

My question would be “What is the objective of Project Planning”?

So your answer should definitely be close to “The purpose of Project Planning is to establish and maintain plans that define project activities.”

One of the keys to effectively managing a project is project planning. The Project Planning process area involves the following activities:

  • Developing the project plan
  • Interacting with relevant stakeholders appropriately
  • Getting commitment to the plan
  • Maintaining the plan

Now the biggest question is what is PLANNING? What do you know by planning, lets see:

Planning includes

  • estimating the attributes of work products and tasks,
  • determining the resources needed,
  • negotiating commitments,
  • producing a schedule,
  • and identifying and analyzing project risks.

It may be required that these activities have to go through various iteration to come up with a project plan.

So here in these articles we will surely not go towards explaining each and every special or generic practice but yes, we will surely talk about the work products. Our plan is to make it very simple for you. So how do you : 

Write an Estimate?

Before this Do you know what is an estimate! An estimate would be how much does it take to make a cup of tea? Or say How much does it take to make a Pizza?

In software development, how much time does it take to write a Webservice, which should take parameter from FB APIs, and return the “Common Friends” between you and your friend?

Now how will you tell me the estimate of this: There are two ways :

One : Guess(ti)mate

Second: Gut feeling

Third: Past experience

Issue with all these is, you eventually have no idea which one may fail or even pass for that matter! And by the way what are the parameter you are defining the estimate?

Coming back to What is an Estimate? 

Estimate is a parameters which includes EVERY information needed by the project to perform necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting.

Hmmmm, sound interesting? Or even sounds familiar. You’ve been doing this, every now and then…you have been telling your leads about your leave plans (Staffing / Resourcing), you also told them about how will you report to them every day end, you also have planned for doing a review of code, which you feel would take half a day…so see, you have ben doing all this…what does this mean…hey you’re already a champ in estimation.

So what is here for you, well a new way to learn “how to Estimate”, and do it in a mature (Level-2) and defined (Level-3) way…

Now as we discussed above as to what should be the parameter? Well parameter should be aaything which instill confidence, LIKE:

Means these parameters include project requirements, including product requirements, requirements imposed by the organization, requirements imposed by the customer, and other requirements that affect the project…

This is good…right, since now you know the basis for vital parameters over which you should do the Estimates…

I guess this will be good for today, tomorrow, we will talk about How to establish a Estimate, Project Plan, and how you can obtain COMMITMENT to the plan… Cheers!