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
resources
and Effectively: while obtaining the desired
result

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

 

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 – 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, 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 no Single 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 Process areas and mapping with Maturity levels

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

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 Level

CMMi Maturity Levels

In Tekriti is at 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.

Another critical distinction is that at maturity level 3, processes are managed more proactively using an understanding of the interrelationships of the process activities and detailed measures of the process.

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

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:

  1. 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 :).
  2. 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.
  3. 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!
  4. 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.
  5. 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!