The most important step that an organization faces while starting its process improvement effort is to decide on the right structure of its quality management system. Once that it done, the job of writing the processes starts which involves selection of process action teams who will be doing the documentation work.

The most common approach

The easiest to think way to do this, is to organize the team as following:

In this approach, you nominate one person (or a group of two) to take care of one individual process area. This seems like a good approach but there are a few problems:

1. Since all process areas are interrelated to each other, it will lead to lot of confusion as it will not be clear how each document should relate the other documents within the QMS. 
2. Creating 18 different procedure manuals, one for each process area does not sound like a good approach. On top of the 18 manuals, I reckon there will be several other manuals and guidelines and the structure itself looks messy. 
3. The coordination amongst the team members will be very difficult as it is almost impossible to set out the dependencies between processes at the beginning of process writing stage itself.
4. The possibility of duplication of work is very high.  

In order to address the problems, I started out by trying to define the interrelationship between the process areas. The diagram below represents, how (according to CMMI v 1.2) the process areas are related to each other.

Dependencies between process areas (PA)

It is very clear from the above diagram that there is very heavy interdependency between the process areas. Thus, allocating the responsibility of each process area to one individual will not work and it will lead to many “holes” that will surface only when the QMS is rolled out.

Thus, a better approach is required that will allow a team to work on group of processes that can be treated in greater degree of isolation. To do this, I tried to analyze the dependencies across rows and columns and found out that PI is the area that has the maximum number of dependencies across the rows and RD and PP has the maximum dependencies across the columns.

Based on analysis I think that instead of creating a team 11 individual players, it will be better to create 4 independent task-forces and each of task force will take care of a group of related process areas. Here is my recommendation for the same:

Task Force 1: RD, TS, PI, RM, VER, VAL
Task Force 2: PP, PMC, RSKM, IPM, DAR, SAM
Task Force 3: OPF, OPD, OT, MA
Task Force 4: PPQA, CM

I have documented the extent of dependencies below.

Task Force 1: RD, TS, PI, RM, VER, VAL

Process depencies within this group on other PAT:

• RD on CM
  a.Ensuring that key work products are controlled and managed as per CM manual
• TS on DAR
  a.Formal evaluation of alternative solutions must be done as per DAR
• PI on SAM
  a.Information on acquiring product components or integration environment
• PI on RSKM
  a.Identifying risks and the use of prototypes in risk mitigation
• PI on CM
  a.Managing changes to interface definition
• PI on DAR
  a.Formal evaluation for appropriate integration sequence
• RM on PP
  a.How plans reflects the current requirements
• RM on PMC
  a.Tracking and controlling activities and work products
• RM to CM
  a.Configuration of changes to requirements
• RM to RSKM
  a.Handling of risks related to requirements

Task Force 2: PP, PMC, RSKM, IPM, DAR, SAM

Dependencies with other teams

• PP on RD
  a. Developing product requirements that define product and product component requirements
• PP on TS
  a. Transforming requirements into solutions
• PP on RM
  a. Managing requirements for planning and re-planning
• IPM on OPD
  a. Information on organizational process assets and work environment
• IPM on Verification
  a. Information on Peer Reviews

Task Force 3: OPF, OPD, OT, MA

Dependencies with other teams

• OT on PP
  a. Training needs identified by project
• OT on DAR
  a. How to determine training approaches

Task Force 4: PPQA & CM

Dependencies : None

Benefits of this approach

I see quite a few benefits of this approach:

• The dependencies between processes are known at the outset and hence process writing will be more effective
• Each task force can have an appointed head from the EPG who can then coordinate with heads of other task-force and iron-out dependencies
• Although the organization can/will have many templates, checklists etc but at the core level there will be only 4 procedure manuals.
• It may seem that the task forces are looking like 4 threads of CMMI i.e. Project Management, Process Management, Engineering and Support but this is a pure coincidence.

The evening of 19^th April was different at our HQ in Kolkata. There was a gathering some senior executives in the CEO’s office where I ran a presentation on the proposal of restructuring the organization. The gathering also included some tehnical leads from our organization. The main idea was to get as many different views as possible. Here is a brief of that:

The current organization structure

In our current structure all authority and responsibilities lies with the functional heads; the structure is created by having separate departments such as Design, PHP, SEO. 

This structure is not “pure devil” and it does have benefits like: 

• It is simple and easy to understand
• Coordination across groups is left to the functional heads
• The organization overhead is low
• The career progression is clear
• Birds of a feather are flocking together 

Disadvantages of this structure? 

• Coordination across departments on project that requires multiple type of specialization is poor
• “CYA” is easy, as the blame can be put on other departments.
• Separation of “management” and “technical” discipline is not there.
• No body is having the full-time job of managing projects and thinking about customer. 

Organizing by project teams 

This will mean creating a structure that comprises of independent, self-sufficient project teams that exist autonomously within organization. This team will be assembled for a specific project under a project manager. The team will be temporary in nature and its member will be reallocated when the project is complete. 

The project will be organized primarily around the project manager, and then a project team is formed. The project manager exercises direct and autonomous control over the various discipline groups and is responsible for the coordination and monitoring of the effort of the team. 

Benefits of this: 

• Flexibility in allocation of resources
• Responsibility for project delivery lies with one person who is clearly identified
• Senior management is free from managing the project as there is now a full time project manager taking care of this. Thus, senior management can focus on Strategy etc. 

Disadvantages of this structure 

• Growth of individual technical skills for a team is not possible or very difficult
• The administrative overhead is very high in managing the resources when they are not allocated to a project
• Leverages exclusively on the project manager for delivery
• The managers may get overloaded with excess inflow of projects. 

The Alternative? Best of both worlds i.e. Matrix Structure
           
In this structure the staff and resources that are required by the project manager are not permanently assigned to the project, but are obtained from a pool controlled and monitored by a functional head. People that are required to perform specific functions in a particular project are allocated as necessary and after their job is done they will be returned to the control of functional head for reassignment. 

The members of the project team and their functional supervisors will have the responsibility for timely completion of allocated task within acceptable quality limits and they will report to both project manager and the functional heads. 

Advantages of the creating a matrix organization 

• It has the benefits of both structures i.e. (current functional organization and project team structure).
• Allows for just-in-time allocation of resources based on problem at hand.
• The project personnel can retain “belongingness” with their functional team and still be accountable for projects as well.
• Allows independent growth in technology and management skills
• The customer relations can be better with having SPOC throughout project lifecycle
• Projects can be controlled better
• Profit margins on the project can be higher as resources having the right skills are allocated for the job instead of just having one person to do the entire thing which may require learning or rework
• Allows projects to be technically brilliant along with being well managed 

Disadvantages of the matrix organization 

• There is a potential for conflict between functional vs. project groups.
• The administrative overhead is higher
• Increase in managerial overhead
• A person may be shifted across projects very frequently which may lead to insecurity. 

So, what’s the conclusion?
Well, to be honest after hours of debate, we are yet to reach one! I will keep everybody posted on what is finally decided.

Any of us who have ever placed a formal bid for a project must have come across absurd prices from competitors that defy common sense. After observing this for a while, it is typical that the organization leaves its own pricing principles and attempt to cut-down or increase its prices.

So how should organizations price themselves? Economics tells us that prices are determined by the dynamic equilibrium of Demand and Supply so that at the equilibrium price the demand and the supply are equal to each other.  In simple English it means, if all you are not pricing high then all your employees should be working on paying projects and it you are pricing too high then you will not have paying projects. On the other hand, if you are unable to keep with the number of projects and the HR department has to work overtime then may be its time to increase your prices.

But, the big fat books on Marketing tell us that pricing should be done based on the perceived value of goods or service and not on its actual value. Thus, even if it costs $250 to make an iPod, it can be sold at $600 and this is how business consultants can demand for such insane prices and we pay them gladly!

The sad truth is that most of the time organizations don’t know how to price themselves. Too often prices are determined by the internal cost structures on the company or prevalent market prices rather than “value” or “demand-supply”. The most common logic is – “we will 4 months on the project and with 2 persons working on, it will cost us X amount of dollars so let’s quote 1.5X for the project” or, “every body is selling it at $400 - $500, lets price it within this range only”

For an average organization that is locked in a bidding scenario, it the option to either under-price or over-price.

Under-pricing is used either as an “account penetration” or “staying in business” strategy. Many times, companies under-price because they just don’t know what to quote. An organization whose sales people are busy placing 50 odd bids on places like Elance etc , really don’t have the time (or may be even the knowledge) to correctly evaluate each project. This is also true for organizations that has under-staffed its sales department. They bid low in order to get the job and within few weeks (or even days) or execution, they realize that the job cannot be completed within the price and they will have to accept losses on the project. In this case the organization simply decides to accept the loss and learn the lesson or it decides to throw in the towel. In former case, this still means that corners are cut, scope is reduced, quality is ignored and the customer suffers. This is because an under-bidding organization is more focused in minimizing its losses than satisfying its customers.

Over-Pricing is the other side of the same coin. If a project is over-priced then there are only two possible outcomes i.e. either the organization will win the business or it will not win the business. If it is not winning the business then it will either adjust its prices or it will go out of business. However, winning an overpriced project poses its own set of problems.  How will the organization allocate budget for an overpriced project? If it expects Y% profit then allocation of (100-Y)% as the project’s budget will lead to excessive project budget which will give an false impression regarding the project’s team performance. On the other hand, if it decides to allocate the normal budget as project’s budget (given it knows what the normal budget is!) then it will lead to abnormal or excessive profits which will sooner or later drive more competition into business and create a pricing pressure.

Thus, in order to sustain the business and maintain the “elegance”, a lot more thought needs to be given on pricing. It is very important to first determine and then monitor the parameters based on which you are deciding how to price yourself better. Please note that “Better” does not means “Higher”!

A process is series of steps or activities that you need to execute in order to solve a problem or come with an outcome or result. Processes exist within every organization, in some cases they are informal i.e. it is not documented but rather institutionalized by habit. Such as, signing the attendance register while entering or leaving office. Documenting the process is a great thing because it gives everyone within the organization a common way to solve the same problem.

People often think that having a process will eliminate the need of having good people in the first place or limit their creativity. This is not true. For example, recipes for food is also sort of a process. A recipe for a chocolate cake may tell you all that is required to know about making one but still, if two people are reading the same recipe, the results that they come up will be different (and in some cases inedible). Same is true for software as well! Having a process makes people work smarter and not harder.

Conduct a search for “Software Development Company” and try to navigate to process page (if you can find one!) and chances are that the general process for software development will be following:

Analyze > Design > Code > Test

If that is true then why the results from two software companies vary so much? In order to answer this question, ask the software engineers to tell you what they do within each of these four phases and the reason will dawn upon you.
The above software development process is too generic in nature and hence it is open for interpretation. For example for you test may mean just mean ensuring that there is no spelling mistake on the page while for me it may mean that it should be XHTML validated as well.

It’s actually the procedure that makes all the difference. While the process answers “what” will be done, the procedure answers “how” it will be done. The more detailed the procedure is, the lesser will be deviation for the expected results and the more consistently the process will be applied. Thus, although Process forms an outline of flow of activities but it is important to probe deeper and find out the procedures as well.

Another important thing to point out is that too often, the process is focused more on the product itself then of the process that is used to create it. For example, writing a ten page document on how to format the code properly is an example of product focus. This will ensure that the code is formatted properly but how do we know that the “right” code has been written? I am not saying that code standards should not be there but I am stressing that the process focus means focusing more on the “means” rather thea of the “ends”.

Some of most frequently encountered problems in software development are faced due to poor configuration management practices such as:

1. Previously fixed bugs miraculously reappear after latest update
2. Development teams are working on separate versions of the code
3. Changes implement earlier have miraculously disappeared
4. A fully tested application stops working
5. There is no way to trace the software requirements to the documents and deliverables.
6. Software teams are using different versions of tools and resulting code is incompatible

Configuration management falls under the category of Support process group of CMMI and falls at Level 2 in staged representation. In essence it is a discipline of establishing the integrity of the work products through proper identification, accounting, auditing and control. Here are the key things involved in this discipline: 

Identifying Configuration Items
Configuration items are identified at the very onset of the project. These typically include work products that are delivered to the customer, internal work products, acquired products, tools and intermediate work product that support the development effort. The following items are generally configurable items: Requirements specification, Architectural specification, Design specification, Code modules, Test data and plans, Project plan, Quality plan etc 

Setting up a Baseline
Establishing a baseline is most important part of configuration management discipline. A baseline represents an approved snapshot of the system at appropriate points in a system life cycle. A baseline serves a platform for further development. This is because before a baseline is established, change can be made informally but after establishing a baseline, change can only be made using a formal procedure.

There are two important terms in respect to a baseline i.e. Build and Release. A baseline that is used for internal development is called a Build whereas a baseline that is delivered to the customer is called a release.

Change Control
As stated earlier, once a baseline is established the only way to make amendments to the “baselined” work product is through formal change requests. Each change request is recorded formally, their impact is evaluated, and they are formally reviewed and then tracked to closure. Changes are generally approved by a change control board (PM can also be a member of the group) and this ensure that adhoc changes are not made to the system.

The change history of each work product should match its current baseline version. This helps the management to answer questions such as – what features has been added to the work product between release 1 and release 2? Often regression testing is also done on the configuration items to ensure that there are no unintended consequences on other configuration items.

Configuration Status Accounting
Configuration status accounting is quite similar to the financial status accounting in a sense it tells about the inflows and outflows that has resulted in the current state of the project.

With a status accounting, the management should be able to answer questions like:

1. How many changes have been received?
2. How many changes approved / disapproved?
3. How many have been implemented / pending implementation?
4. What differences exist within successive baselines?

Auditing the Configuration
Finally, the system is audited, mostly prior to customer delivery to ensure that all change requests have been resolved and that the system contains only the work products that are required and nothing more. This is done by comparing the documentation (SRS, Manuals etc) to the product to ensure that it is ready for delivery.
Word of Advice!

Configuration Management is discipline in itself that requires infrastructure, effort and cost. Thus, these activities should be included in the original project plan itself otherwise it might seem like an overhead to do them later and the organization will make a costly mistake of ignoring this discipline

Risk Management is a fundamental discipline for any planning process. Risk is defined as a possibility of a loss and has a probability associated against it. As a manager, it is important to continuously monitor risks and take actions to mitigate them. Dr. Robert Charette said that risk management is not about future decisions but, future of present decisions.

The process to identify risks starts the beginning of the planning process itself. All the participants brainstorm to find out all the possible risks that may affect their plans. Then a monetary value is put against the risk which represents the amount of loss that will incur if the event actually occurs and finally, a percentage value is put against the risk item that represents the probability of the risk actually occurring. The impact of the risk is calculated as a product of probability and loss amount. This gives managers a way to prioritize risks and manage them effectively. For risks that can adversely impact our plans, it is also important to write up a contingency plan i.e. what will we do if this risk occurs.

Decision making under a scenario of chaos is normally not as effective. I think the biggest benefit of risk planning is that it helps us in executing a pre-planned action at the time of chaos. This is because the action has been planned thoughtfully before the risk has actually occurred and hence the element of urgency does not cloud the judgment. For example, a data centre might consider fire as a risk to its facility and servers. Now, unless a plan has been drawn up earlier that tell the superintendent on duty about what to do in case of a fire, it will be difficult to take the “right action” or take “all the actions” that might be required to protect the facility and data in case there is fire.

Too often within the planning process, people write down known issues as risks. Known issues are problems and not risks. For example, if you know that your organization does not have the skills to deliver the project then it’s a problem – not risk! You have to deal with it right away.

A problem is a risk that has already been realized. They have a 100% probability.  The only reason someone wants to put a known problem as a risk is because they don’t want to deal with it right away. It’s same as saying – “OK! I know we cannot deliver this project but let’s put this down as a risk as we will deal with it later. Let’s focus on getting the SOW signed now”.

This is wrong! Problems must be dealt with as soon as the identified and Risks can only be dealt with once they are occurred. In a nutshell, Risks always deal with future events and not present while whatever is known right now is a problem and not a risk.

Thus as a customer, if  you ever come across a risk management plan where problems are listed as risks then you should be aware and ask your vendor to address them right away i.e. before the plan is approved.

As promised in my last post, we have given some love to web design services page of Design2Please.com in last 2 days. Here is a small slice of the page to give you a feel of it:

We thought the page was too busy and less focussed - things were everywhere on the page and people could get distracted. The portfolio screenshots were too small and was not going with the flow.

So, we did the following changes in the new page:

• Came out of 2 column structure and created a single flow.

• Removed some bulleted points from the features list as they are quite obvious ones for any custom website created by a company like us. (And we also thought if people have questions they can ask us anytime.)
• Inserted Dedicated Hiring ™ pricing model option just after the web design packages for the convenience of the visitors. This will help visitors to compare the prices and select what’s best suited for them.
• Portfolio screenshots are much bigger and so more visible.
• Inserted the link to web design process we follow. So visitors can also read about our work process before they select to work with us. This will make the communication much clearer. (We are currently redesigning the process page to make it more crisp, graphical and easy-to-understand).
• “Get Started Now” (Request Free Quote) form is available at the bottom of the page. Previously it was hidden and was only available on clicking the “contact sales” button. Now it’s available to everyone, so anyone can get in touch with us with any question he has.
• We have made “Get Started Now” form in reverse (white on dark) to make it stand out from the rest of the page. It will also help to indicate that this section is interactive, which is different from the rest of the page area (that’s only for reading).

We will be making many changes to the website soon. I’ll update you. Be there!