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

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

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!