TekUI

CMMi - Process Area - Requirement Development - Part II

2012-02-11T09:34:00.000-08:00

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.

: 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

2012-02-10T13:22:00.000-08:00

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:

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!
We develop the requirements for the entire life cycle of the project
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:

You should create a requirements baseline that does not change unless there is an approved change request.
Investigate, Impact, and Review all proposed requirements changes with the relevant stakeholders (approved or rejected), and
The changes to the baselined requirements should only be made once they are approved and appropriately update the traceability.

We will learn more about requirements development in next few posts! Cheers

CMMi - Project Planning - Resourcing

2012-02-08T12:34:00.000-08:00

Ironically, though resourcing the product team members is a very important and significant part of a project manager's role, not much focus is placed on resourcing. Because of this, we've encountered many project managers that are overwhelmed, worn out, and in many ways, well ineffective. Who to blame for?

In my own projects, I have been so very little blessed with good resourcing, and I am not talking from the perspective of 'Skills', I'm talking about manpower! 30% here, 10% there, 10 % I don't know where, and remaining 50 % of the same resource already is planned for some other projects! Seems familiar...wow! look at the smiling faces of few PMs around :)

Image via Wikipedia

So rather than giving 'Gyan', let me ask you a very simple question, and before that; Resourcing is not just 'Man-power', resourcing includes, but not limited to, manpower, equipment, methods etc. So my question would be:

How do you plan for the necessary facilities? How do you plan for the necessary staff?

The top-level WBS, remember we developed it under estimation mechanism is typically explained / expanded by decomposing the top levels into small workable items that that can be separately assigned, performed, and tracked.

Now as this may be seen as additional work, but believe me, always remember to 'Break-it-down', this is so very important in our estimation and resource allocation methods.

You can or in fact should assign WBS a unique identifier (e.g., number) to permit tracking. A WBS generally is based on requirements, activities, work products, or a combination of these items.

So to answer the question that I asked, You do it this way:

You can provide excerpt from Project Plan (Say Project Delivery Approach), the MS project plan, or any other means of WBS of the project plan that identifies the need, available tools, schedule and budget etc.

You should provide excerpt from Project Plan that identifies staffing need, available staff resource, and plan for recruiting etc.

CMMi Introduction

CMMi - Project Planning

CMMi - Project Estimation

: Scope of Work - MS Excel Work Breakdown Structure template (Photo credit: IvanWalsh.com)

CMMi – Project Planning – Identify Risk

2012-02-07T11:22:00.000-08:00

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)

: 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.

We should identify the Risks.
Analysis of the risk, and determination of the impact, probability of occurrence
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:

: 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!

For previous segment of this series, please visit:

CMMi Introduction

CMMi - Project Planning

CMMi - Project Estimation

Project Plan - How to Budget and Schedule!

2012-01-31T12:57:00.000-08:00

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!

Cheers!

CMMi – Project Plan – Introduction

2012-01-30T09:52:00.000-08:00

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:

Establish the Budget and Schedule?
Identify the Projects?
Plan for Data Management?
Plan for resourcing?
Plan for Knowledge transition / Training?
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 – Estimation Continued!

2012-01-26T05:14:00.000-08:00

Ok, so we were talking about the Project Planning, and under Project Planning we were over to the first part which is Estimation. So what actually estimates include?

We know about Guess(ti)mate, Error-n-Judge-n-implement, Experience, and Ball-park! But, to achieve at a new way to learn “how to Estimate”, and do it in a mature (Level-2) and defined (Level-3) way…let’s get started:

Whenever you start doing estimate, you’ve to understand about the work, which is supposed to be done by your resources. We call it, WBS (Work Breakdown Structure). This is primarily done to understand the scope of the project.

At the beginning of the project, this may term as a factor for initial Estimate. The objective of this WBS is to divide the overall project in to s,all interconnected set of manageable component.For eg., say you’ve to develop an eCommerce site, which will include:

- Evaluate the potential of current website
- Communicate on the said plan
- Decide upon its potential and prospective decisions, whether to restyle or replace (if required)
- Differentiate key areas to manage and organize the project
- Implement sales, tasks, employee, product, client and money management solutions
- Devise customized solutions to heighten the sales and achieve the coveted goals

Now a WBS will mean coming up with the timings on each of these actionable items. So youSHOULD ”identify and organize” the logical units of the work which is to be managed.

Once a WBS is defined you’ll then have a reference which will be used for assigning Efforts, Schedule,Responsibility for coming up with a plan.

Now while defining WBS you should consider the following:

Risk and how you’re going to mitigate them
Task for deliverables
Tasks for Skill, Knowledge, and Training sessions
Tasks for Development plan, QA plan, and Configuration management plan

The more detailed the WBS is the more realistic this will turn out to be. An example would be (Courtesywikipedia):

WBS

Now once we have identified the scope of the project at a high level, now is the turn to establish the estimates of the work products:

In many of the associated models which are used to estimate effort, cost, and schedule of the work, SIZE is the major input. You can also include SLAs (Service Level Agreements), Connectivity, and Availability etc.

Lets see a bit of examples:

Number and complexity of requirements
Number of functions that you’re going to use
Function points – what all are function points
Source lines of code – especially in OpenSource
Experience of project participants
Number of classes and objects – This is something architecture needs to define
Number of database tables – The database and the structure needs to be defined and understood
Number of fields in data tables
Architecture elements
Amount of code to be reused versus created
Number of inputs and outputs
Number of technical risk items
Proximity of customers, end users, and suppliers
How agreeable or difficult the customer is
Quality and “cleanliness” of the existing code base

One important point to consider is that while determining the estimates, your estimate should be in sync with project requirements.

You should definitely talk about the technical approach which defines a strategy for development of the product. It includes decisions on architectural features, such as distributed or client/server; Cloud based computing etc.

The last thing that you would need for is to learn about “How to learn about Estimating Efforts and cost”

This is an essential component for Project Planning.

The objective is to Estimate the effort you are going to put in project and cost for work products. This is primarily based on estimation rationale.

You should collect all the historical data to convert the attributes of work products in to estimate of resource hours and cost.
You can also use estimation techniques like: Examples of effort and cost inputs used for estimating typically include the following:
- Estimates provided by an expert or group of experts (e.g., Delphi method)
- Critical competencies and roles needed to perform the work
- WBS
- Skill levels of managers and staff
- Knowledge, skill, and training needs
- Product and product component requirements
- Size estimates of work products, tasks, and anticipated changes
- Capability of tools provided in engineering environment
- Technical approach

With this we come to an end of understanding of Estimates, and the techniques required for estimation, now another step would be to understand about the how to develop the Project Plan. Till then Cheers!

CMMi - Project Planning - Estimation

2012-01-24T10:03:00.000-08:00

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

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!

CMMi – Project Planning

2012-01-23T10:34:00.000-08:00

CMMi – Project Planning

23JAN

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.

Now 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

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?

We will begin on this tomorrow...till then you should think about how do you do this in your Project?

CMMi – Tailoring the processes!

2012-01-20T09:30:00.000-08:00

Most of us have this question that why is it that one process or procedure can’t be implemented in all the projects with similar flavor! Why is that you’ll talk new, tailored processes for every project?

CMMI, is smart enough to recognize that one size does NOT fit all. Organizations which are tempted into the “one true process” quickly realize that actually “one size fits no one”. Even if the you create “one true process” by carefully looking at projects in progress at the time, no two projects can ever be the same and hence noSingle process really fit new projects as they come along.

In fact CMMi is smart enough to make sure and embodies ideas to stop organizations falling into the “one true process” trap.

This is how we have been doing this at Tekriti. We first as part one of this entire exercise are trying to build a “set of standard processes” – enough processes to support the different types of projects that the organization has to deliver. We can think of these types of projects as forming families – for each distinct family there is a distinct standard process.

Then since CMMi allows us, we will go further and tailor the selected processes to better fit the needs of each specific project. Tailoring can only occur within permitted guidelines – to ensure that the performance of different projects remains comparable. In particular, the quality of the work products produced will be comparable across projects.

CMMi is so very beautiful in terms of giving us further allowance for very unusual projects. Recognizing that every organizations evolve continuously and will have to tackle new and unique challenges, projects are permitted to seek exceptions to the standard processes and tailoring guidelines. But there is a condition, your project has to have a reasonable case for its exceptional behavior and describes how it will perform its work to ensure that the organization’s policies will not be violated.

If your organization is attempting “one true process” well, then from CMMi side you’re not fulfilling its requirements – they cannot achieve maturity level 3.

The “one true process” becomes a straight jacket that is almost impossible to change.

Now you may ask question that isn’t it easier to change one process than to keep several processes current? For to be kept up to date, that’s certainly true. But consider the problems from the other side. Different projects have different needs and it is though always good to have one process which fits all, BUT the problem comes when these projects requires contradictory changes – one project needs more agility, the other more formality…

Now, which changes are we going to incorporate into the process? If we incorporate more formality, the agile project is disadvantaged. If we go for more agility, the formal project is disadvantaged.

And then, very quickly the strains on the process and the demands to change the process become so great, the “one true process” becomes an unsustainable position. Then comes the problem, which you never have solution for!

So One size NEVER fits all! And this is something you’ll will learn as and when we will come and talk to you all, and make you understand about the processes…and make you realize that your project needs are different from someone else’s, and hence a different process!

CMMi – Capability Model

2012-01-18T09:01:00.000-08:00

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.

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.

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!

CMMi Process areas and mapping with Maturity levels

2012-01-17T07:23:00.001-08:00

From CMMi Introduction and Maturity level understanding, we are all set to understand the process areas associated with every maturity level. And the jargons will be Process Areas (PAs). Uh ho!, another jargon, again processes and all?

Well don’t worry about this, we have lot to cover and we will on the way keep on explaining as to what these jargons are, for today lets see this section. As this is very important for all of us to understand about the processes, let’s focus on this only for today!

Level	Focus	Key Process Area	Result
5 Optimizing	Continuous Process Improvement	Organizational Innovation and Deployment Causal Analysis and Resolution	Highest Quality / Lowest Risk
4 Quantitatively Managed	Quantitatively Managed	Organizational Process Performance Quantitative Project Management	Higher Quality / Lower Risk
3 Defined	Process Standardization	Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Mgmt (with IPPD extras) Risk Management Decision Analysis and Resolution Integrated Teaming (IPPD only) Org. Environment for Integration (IPPD only) Integrated Supplier Management (SS only)	Medium Quality / Medium Risk
2 Managed	Basic Project Management	Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management	Low Quality / High Risk
1 Initial	Process is informal and Adhoc		Lowest Quality / Highest Risk

CMMi – Maturity Levels – Initial – Managed – Defined

2012-01-16T09:59:00.000-08:00

CMMi – Introduction to Development 1.3 : This is where we discussed about introduction to CMMi! Let’s move ahead and learn a bit more about Maturity and its associated parlance in real life.

So after understanding a bit about CMMi processes, what they are, what type os levels do we have in CMMi (Performed, Managed, Defined and so on…O. So let’s talk about this: If I ask you what processes are you following in your organization or in your project or do you even follow a process while you come to office from your home? Well the answer to all these is YES! There is process involved at each and every step of your journey. You learn alphabet via processes, you learn to cook via processes, you learn to drive via process…and each and every process and its stage is Performed, Managed, Defined, and then Optimized…

CMMi Maturity Levels

In Tekriti we are at Maturity level 1 and or 2. We have been doing 3 all the way of our journey, but what we haven’t been doing is the organized way! We have been reactive most of the time and occasionally pro-active. So why shall we improve? For Clients? For our CEO? For our Business? No…No…No…You should improve for yourself…rest all will follow. As someone rightly pointed out, “If we do what we have been doing throughout the day in an efficient and effective manner, half of the “Innovation” is done!”

Maturity Level Details:

Maturity levels consist of a predefined set of process areas. The maturity levels are measured by the achievement of the specific and generic goals that apply to each predefined set of process areas. The following sections describe the characteristics of each maturity level in detail.

Maturity Level 1 – Initial

At ML (Maturity Level) 1, processes are ad hoc and chaotic. There is no stable environment in the Organization. Success in these organizations depends on the competence and heroics of the people in the organization (Remember I mentioning about depending on Heroes) and not on the use of proven processes.

ML 1 organizations will be able to execute the work; however, they frequently exceed the budget and schedule of their projects.

ML 1 organizations are characterized by a tendency to over commit, abandon the processes in the time of crisis, and not be able to repeat their past successes. This is very crucial, not able to repeat the success of the past. Does this remind you something? Did I hear some one say Uhh….kinda happened to me and my project? Believe me you’re not alone!

Maturity Level 2 – Managed

At ML 2, an organization has achieved all the specific and generic goals of the maturity level 2 process areas. This is highly significant, as this is the building block for all your further activities. Doing Generic Goals and Specific ones, make it easier for you to have a kick start to ML3. The projects of the organization have ensured that requirements are managed and that processes are planned, performed, measured, and controlled.

At this level we maintain that the existing practices are retailed during stress times…if the practices are in place then you have a better and managed performance according to the plan

At this level you have requirements, processes, work products, and services all managed. The entire status of the work related products (Like Requirement docs, Project Plan, Estimation etc.) along with the delivery of services are visible to management at defined points.

All te stakeholders are kept involved, they know about where we are…what is left and so on….

Maturity Level 3 – Defined

At ML 3, an organization has achieved all the specific and generic goals of the process areas assigned to maturity levels 2 and 3. There is a massive learning curve from processes perspective here at level 3.

A critical distinction between maturity level 2 and maturity level 3 is the scope of standards, process descriptions, and procedures.

At ML 2, the standards, process descriptions, and procedures differ from project to project, there is NO Organization level standard among the processes being followed. We do this and are good, and you do another one, and you also survive, but there is no STANDARD Org level process form which we can tailor all our prject level processes.

At maturity level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit.

The processes that are performed across the organization are consistent except for the differences allowed by the tailoring guidelines.

Since we are targeting the CMMi V1.3, and hence I am not going in the details of ML4 and ML5.

CMMi – A crash course – Introduction to Dev 1.3

2012-01-14T06:20:00.001-08:00

Capability and Maturity

CMMI is an acronym for “Capability Maturity Model Integrated.” The last word basically means that CMMI is a fusion of best practices from a number of different capability maturity models that were eventually combined into a single model that is reminicent of the CMM.

Maturity means that whatever the company is doing, the company does it in a way that is well-documented, where everyone knows what is expected of them and perform accordingly, where performance is not dependent on heroes, and where decisions are made on proper analysis of the situation.

So there are three types of CMMi : Development, Acquisition, and Services. We at Tekriti are going for CMMi Dev Level 1.3

What holds everything together? It is the processes used in your organization. Processes allow you to align the way you do business. They allow you to address scalability and provide a way to incorporate knowledge
of how to do things better.

We all have our problems associated in day-to-day activities, CMMi provides you a way to solve these issues by providing streamlined methods. We will discuss and learn about all this in a matter of time and with every session as we move ahead!

Let’s start talking by Maturity!

Levels of Maturity

Search for CMMI on the web, and you’ll find the five levels of CMMI:

Performed. - This is where everyone starts: Our company is making products and you’re earning money, so evidently you’re doing something right. But you’d have a hard time describing precisely how you’re doing it. Your project teams may be managing by the book, but they certainly can’t tell you which book. You’re performing, but you don’t really know why or how well. I mean if I ask you now, do you follow the processes, well you’ll say Aaannn….you know …no! Well I don’t buy your argument then…you’re following processes that is why you ‘re here speaking with us and doing what you are “Supposed” to do.

Managed. - At this level, your company’s project teams are well-functioning according to ordered methods that are well-documented. There’s no guarantee that one project team is managed by the same methods as another team, however, and each time a new project is started, you may find the team reinventing the wheel.

Defined. - This is where all of the methods are well-defined across your company, and all of the projects perform according to those methods rather than figuring them out on their own. And this is what we are targeting at Tekriti!

Quantitatively Managed. - The projects perform according to the same methods as at the “defined” level, but at the quantitatively managed level the projects will have plenty of hard data to back their decisions and performance. This enables the projects to make sound decisions and quickly identify deviations, and it obviously requires that the defined processes have been followed for a while.

Optimizing. - At the last level, the organization continuously focuses on optimizing its work processes. This requires plenty of statistics from the quantitatively managed level.
Since all companies start at level 1, the CMMI model doesn’t state any requirements below level 2. Level 2 is concerned with project planning and processes for managing projects, requirements, and suppliers, and introduces “support” processes that are vital for further maturity: configuration management, metrics and analysis, and quality assurance.

Level 3 introduces a large number of processes. Risk management is added to the project management toolbox, and the project management processes are expanded with processes for integrating separated teams in the management. This level also introduces three processes aimed at defining processes at company level rather than project level. Level 3 also involves processes for constructing products according to well-developed requirements, and for verifying and validating the products.

Level 4 adds processes for assessing objectively how the various processes perform, and for managing according to objective metrics and statistics.

Finally, level 5 provides processes for maintaining an organizational environment for innovation and for identifying and correcting the cause of problems and inefficiencies in the processes.

Well…this is it for today….will catch you soon with other sessions…Happy “Processing” Cheers!

Making Changes in Website - Keep these things in mind

2011-10-20T06:22:00.001-07:00

Do you feel like your site needs a tune up? Do you feel like that the traffic you once had is slowly disappearing?

And you got this hunch to revamp your website. Well, before you take this call to revamp your site, develop a strategy or plan of sorts. Write down or make a map out for what you want to do and make sure that it will accomplish your goals.

1. Decision about "Rebrand or Not to Rebrand?"

While making a decision about the rebrand or a change in logo:

Your first consideration should be whether you should rebrand. Is your logo working for you? Do you EVEN have a logo?

. “A logo design image should be carefully chosen”, since “a strong image can take a long time to build but an even longer time to shed”, as quoted from a study by the University of Texas at Arlington.

2. What about SEOs, the guy with Traffic?

What are you talking about? Well of your website was part of DOTCOM boom, you never had even thought about SEOs, who they are? Well they are the best way to get your site to the top of the search results. This is crucial as you probably know now.

Hiring an SEO is very important in the planning stages of your website redesign. They will help you to build the site to be search engine friendly. But no one can ever guarantee you about # ONE Rank. If someone does, ask him to sit outside!

When hiring as SEO check for their experience in your particular industry, country and city are very important as well. Ask them to share the changes to your site too.

3. My Return on investment?

Now when you have a shiny new logo and brand new color scheme, and traffic because your totally awesome SEO, this is the time when you need to figure out how to get these customers keep coming back. Give them what they want.

Offer online purchasing of your products. Add a shopping cart application function.

You should definitely have a newsletter. Send out a weekly or monthly newsletter to keep your business in front of your visitors. Always make sure you are giving them the reason to go back to your website for more.

Plan well, ask for feedback and evaluate your logo. When planning a redesign of your website include SEO. Customer should be bale to find you at ease. Your navigation links, Header, Footer should be in place. There should not be any broken link on the website, and when this is accomplished...you should see your site flourishing.

92% of Marketers Agree: Content Is Critical for SEO [Infographic] (hubspot.com)

How to design a right team for UX

2011-10-18T15:18:00.000-07:00

Building the right UX team requires great commitment and investment. UX is no longer just a nice-to-have niche, but is now at the core of how brands are built offline and yes you're right online too.

The user expectations and the field of UX will continue to grow, it is critical for companies to change their approach to how they come up with a right mix for their UX team.

Here is a thing...UX teams should now, whether they focus on enterprise grade products or consumer products, must understand the strategic business opportunities while still being tactically focused to execute pixels with precision. This requires a new definition altogether, bringing together three major aspect of a product: Business Strategy, Interaction Strategy, and Content Strategy. This is significant improvement, if you give it a thought....your X team until and unless they align their though process towards overall vision (Which emanates from strategy itself), they would never be able to comply with the overall vision of company. The UX team of today should have market research, data analysis, and technical expertise.

Not having a proper mix of UX skill set...you do it on your own risk... Orgs that don’t adapt will fall behind, under serving their brands, their users, and ultimately their bottom lines...

Come Together:

Come together...get this done...Product marketing, UX, and engineering need to work together. The agency, client, UX, technology, and creative should be very well connected with each other.

Well, all of these functions may have different goals and ways they are measured, but they must be in sync and always be integrated towards user experience, usability and what they are trying to accomplish.

Challenge Yourself:

Always ask 'WHY', rather than 'How' and 'What'. Take the time out to ask the question...this is the most easiest and efficient way to gather user data...which involves client, customer...and end users.

Do a qualitative and quantitative data study, which should be supported by experienced and well-informed intuition.

Beware of:

You will know your team is not engaged in the outcome when you see few of these important warning signs:

Nobody is using the product or wearing a customer hat. When your UX team does not think about how does it feel and what does it take to think from user perspective.
Your engineering team has no idea about what to build and nothing meaningful is being produced.
Designers can’t explain the rationale behind design they’ve made in their designs and how they inend to give benefit to the user.

A sign that a team is engaged and working well together is when they are speaking a common language and are keeping the problem they are trying to solve and the user’s goals in the center of the conversation. So...are you ready to have a skill-mix...?

TekUI

CMMi - Process Area - Requirement Development - Part II

CMMi - Process Area - Requirement Development - Part I

CMMi - Project Planning - Resourcing

CMMi – Project Planning – Identify Risk

Project Plan - How to Budget and Schedule!

CMMi – Project Plan – Introduction

Project Planning

CMMi – Project Planning – Estimation Continued!

Ok, so we were talking about the Project Planning, and under Project Planning we were over to the first part which is Estimation. So what actually estimates include?

CMMi - Project Planning - Estimation

CMMi – Project Planning

CMMi – Project Planning

CMMi – Tailoring the processes!

Most of us have this question that why is it that one process or procedure can’t be implemented in all the projects with similar flavor! Why is that you’ll talk new, tailored processes for every project?

CMMi – Capability Model

CMMi Process areas and mapping with Maturity levels

CMMi – Maturity Levels – Initial – Managed – Defined

CMMi – A crash course – Introduction to Dev 1.3

Making Changes in Website - Keep these things in mind

Related articles

How to design a right team for UX