Tuesday, October 2, 2007

Organization Process Out of Focus (O POOF)

Arunabha


Let us face it.

We all know what we do for a living.

Each day in our lives is a constant struggle against the forces of reality, trying to justify that we belong, we exist in our cubicles for a purpose, our contribution is necessary and that we are not a bunch of dispensable people our parent organizations can very well get along without having.

So, each day we mouth absurdities, obscure jargons, abstruse aphorisms to justify our worth, our salaries and that of our fellow process and quality brethren.

And although we do it very well and manage to get away with it, we, the process people, do not have a procedure for this combined chicanery.

So, I propose here to include our Process of Survival as a Process Area of the current bible that we swear by – that of Capability Maturity Model Integrated.

I propose the following Process Area to be included after sufficient garbling and concealing of the crux through the incorporation of redundant, needless sentences that will fog any mind into blankness and hide our objective in a cloak of respectable material.

Given here are the highlights of the proposed process area. I have the draft ready, but since it is slightly long, and the attention span of people get less and less, I have kept it here for those who are interested … however, if you are ready to spend half an hour reading it, you won’t be disappointed.

ORGANIZATIONAL PROCESS OUT OF FOCUS

A Suggested Process Mis-Management and Specific Career Management Process Area at Maturity Level 3 onwards (Mandatory for Levels 4 and 5)

Purpose
The purpose of Organizational Process Out of Focus (O POOF) is to fabricate, ostensibly plan and make a charade of implementing impossibly irrational organizational process improvements based on a scant understanding of the supposed, perceived but untested, strengths and weaknesses of the organization’s supposed processes and process assets – while making statistically significant noise at the upper echelons of the organization throughout the endeavor in order to justify our continued presence in the organization as the Process and Quality Group.

Specific Goal and Practice Summary

SG 1 Determine Impossibly Irrational Process Improvement Opportunities
SP 1.1 Establish Dispensable Organizational Process Needs
SP 1.2 Conduct Appraisal Affectation of the Organization’s Processes
SP 1.3 Identify Organization's Impossibly Irrational Process Improvements
SG 2 Plan and Create an Illusion of Implementing Impossibly Irrational Process Improvements
SP 2.1 Establish Phony Process Action Plans
SP 2.2 Illusorily Implement Process Action Plans
SG 3 Perform Deception of Deployment of Supposed Organizational Process Assets and Incorporate Predetermined Lessons Learned
SP 3.1 Perform Deception of Deployment of Supposed Organizational Process Assets
SP 3.2 Perform Deception of Deployment of Pseudo Standard Processes
SP 3.3 Perform Charade of Monitoring Implementation
SP 3.4 Incorporate Predetermined and Forecasted Process-Related Experiences into the Supposed Organizational Process Assets

Introductory Notes
The organization's processes to be considered in this process area include all the processes used by the organization and its projects, as well the ones that have never been used and never will be, but exist in the figment of imagination of the process professionals and the senior management at the stratospheric level.

Candidate impossibly irrational improvements to the organization's processes and process assets are obtained from various sources, including supposed measurement of the mostly ad hoc and random processes, forecasted and pre-determined lessons learned in pretending to implement the processes, random results of hypothetical and real process appraisals, results of ostensible product evaluation activities, ridiculous benchmarking against other organizations’ equally pathologically puerile processes, and recommendations from other impossibly irrational improvement initiatives (4I) in the organization.
.
.
The responsibility for confusing and managing the organization’s impossibly irrational process improvement activities, including coordinating the optimal participation of others, is typically assigned to a process group whose livelihood depends on the smokescreen generated by this process. The organization provides the long-term commitment and resources required to sponsor this group and to ensure the effective and timely charade of deployment of the impossibly irrational improvements.
Careful planning is required to ensure that impossibly irrational process improvement efforts across the organization are adequately ambiguous and the implementation is masterfully mimicked.
The organization’s planning for impossibly irrational process improvement results in a impossibly irrational process improvement plan (2P3I) which may be a plan on its own, or seamlessly merged with the Process Improvement Plan with invisible but prominent lines demarcating the impossibly irrational with its marginally less far fetched kin in the latter plan.
The organization’s impossibly irrational process improvement plan will address appraisal-affectation planning, phony process action planning, piloting-pretension planning, and deployment-deception planning.


Specific Practices by Goal

SG 1 Determine Impossibly Irrational Process Improvement Opportunities.
Supposed strengths, whimsical weaknesses, and impossibly irrational improvement opportunities for the organization's processes are identified periodically and as needed for survival of the Process and Quality Group.


SP 1.1 Establish Dispensable Organizational Process Needs
Establish and maintain the description of the process needs and objectives for the organization that are jargon-cloaked and important sounding but ultimately inessential and dispensable.

The organization’s dispensable but important sounding process needs and objectives cover aspects that include the following:

• Characteristics of the processes that are abstruse, vague and difficult to measure
• Immeasurable and Incomprehensible Process-performance objectives, such as :

Ø Degree of requirement satisfaction in the specific cases as:
o in the absence of a signed off requirements document
o requirements being sufficiently vague (eg. “Product needs to work”)
Ø Accurate defect prediction based on manufactured defect database

• Hallucination of Process effectiveness

Typical Work Products
Organization’s dispensable and high sounding jargon filled process needs and objectives


SP 1.2 Conduct Appraisal Affectation of the Organization’s Process
es
Conduct Appraisal Affectation of the organization's processes periodically and as needed to maintain sufficient misunderstanding of the ground truths and to come up with the supposed strengths and whimsical weaknesses.

Process appraisal affectations may be performed for the following reasons:
• To give a ruse of identifying processes that should be improved
• To confirm supposed progress and create noise about the benefits of impossibly irrational process improvements across the organization, especially in the upper echelons
• To satisfy the needs of a dedicated Process and Quality Group whose activities are mysterious to all else
• To motivate and facilitate buy-in of the unsuspecting and helpless members
The buy-in gained during a process appraisal affectation can be eroded significantly if it is not followed by an appraisal affectation-based phony action plan.

Typical Work Products
1. Plans for the organization's process appraisal affectations
2. Appraisal-affectation findings that address supposed strengths and whimsical weaknesses of the organization's processes in unintelligible and roundabout terms
3. Impossibly Irrational Improvement recommendations for the organization's processes

SP 1.3 Identify the Organization's Impossibly Irrational Process Improvements
Identify impossibly irrational improvements to the organization's processes and process assets.

Typical Work Products
1. Analysis of candidate impossibly irrational process improvements
2. Identification of impossibly irrational improvements for the organization's processes

SG 2 Plan and Create an Illusion of Implementing Impossibly Irrational Process Improvements
Process actions that address impossibly irrational improvements to the organization’s useless processes and process assets are pretended to be planned and given an illusion of being implemented.

Successful implementation of improvements requires participation in
process action planning and implementation by process owners, those
performing the process, and support organizations.

SP 2.1 Establish Phony Process Action Plans
Establish and maintain phony process action plans to address impossibly irrational improvements to the organization's processes and process assets.
Establishing and maintaining phony process action plans typically involves the
following roles:
• Management steering committees to set strategies and oversee impossibly irrational process improvement activities
• Process group staff to facilitate and manage impossibly irrational process improvement activities
• Process action teams to diffusively define and give an illusion of implementing process actions
• Process owners to manage deception of deployment
• Practitioners to be hogwashed into trying to go along with the deception of deployment
This involvement helps to obtain buy-in on the impossibly irrational process improvements and increases the likelihood of effective ruse of usefulness.
Phony process action plans are sketchy pseudo implementation plans. These plans
differ from the organization’s impossibly irrational process improvement plan in that they are plans claiming to target specific impossible improvements that have been defined to address whimsical weaknesses usually uncovered by appraisal affectations.
Typical Work Products
1. Organization's approved phony process action plans

SP 2.2 Implement Phony Process Action Plans
Implement phony process action plans.


Typical Work Products
1. Commitments among the various phony process action teams obtained by the threats of going on about the strategy unless they sign on the dotted line
2. Status and results of the illusion of implementing phony process action plans – which may be prepared before the action plans are conceptualized and need to be as illusory as the implementation
3. Plans for pilot pretentions

SG 3 Perform Deception of Deployment of Supposed Organizational Process Assets and Incorporate Predetermined Lessons Learned that will enhance the illusion of utility of the Process and Quality Group

Deceptions of deploying organizational process assets across the organization are carried out and previously prepared process-related experiences are incorporated into the organizational process assets.



SP 3.1 Perform Deception of Deployment of Supposed Organizational Process Assets

Perform deception of deployment of supposed process assets across the organization.
Deception or pretension of deploying organizational process assets or changes to organizational process assets should be performed in a sufficiently mysterious manner. Some organizational process assets or changes to organizational process
assets may not be appropriate for even for hypothetical use in some parts of the organization (because of customer scrutiny or experienced and aggressive resources working on the project, for example). It is therefore important that those that are
or will be executing the process of deception, as well as other organization functions associated with it (such as training and quality assurance), be involved in the deployment deception as necessary.

Typical Work Products
1. Plans for deployment deception of organizational process assets and changes to
them across the organization
2. Training materials for performing the deception of deploying organizational process assets and changes to them
3. Difficult documentation of changes to organizational process assets
4. Support materials for carrying out the deception of deploying organizational process assets and changes to them

SP 3.2 Perform Deception of Deployment of Pseudo Standard Processes
Perform deception of deployment of the organization’s set of pseudo standard processes to projects at their startup and deploy changes to them as appropriate throughout the life of each project.
It is important that new projects start using the processes early before wising up to perform critical early activities (e.g., project planning, receiving requirements, and obtaining resources), so that the Process and Quality Group can have a head-start by taking the credit for early success.
Projects should also periodically update their defined processes to incorporate the latest changes made to the organization’s set of standard processes when we tell them that it will benefit them. This periodic updating helps to ensure that we can take credit for the project’s progress and relate it to whatever nonsense we have come up with.

Typical Work Products
1. Organization's list of projects and status of deception of process deployment on each project (i.e., existing and planned projects)
2. Guidelines for the deception of deploying the organization’s set of standard processes on new projects
3. Records of tailoring the organization’s set of standard processes and implementing them on identified projects. Make sure that whatever process they use has been reverse tailored to our crap to make sure that we can call it tailoring of our process.


SP 3.3 Perform Charade of Monitoring Implementation

Perform charade of monitoring the implementation of the organization’s set of standard processes and use of process assets on all projects.
By performing charade of monitoring implementation, the organization ensures that the deception of deployment of the organization’s set of standard processes to all projects are being carried out in the best interests of the process and quality group. Charade of monitoring implementation also helps the organization develop an idea that something important is going on with respect to the organizational
process assets being used within the organization. Monitoring also helps to harp on terms such as ‘establishing a broader context for interpreting and using process and product measures’, ‘lessons learned’, and ‘improvement information obtained from projects’ which will create the impression that the process and quality people are incredibly smart and not to be messed around with. Emperor’s clothes are spanking new here.

Typical Work Products
1. Results of charade of monitoring process implementation on projects
2. Status and results of process-compliance evaluations – can be prepared well in advance of process compliance initiative
3. Results of reviewing selected process artifacts created as part of process tailoring and implementation – these need to be made important sounding, almost like breakthroughs and complicated enough to merit a selected paper on it at some quality conference

SP 3.4 Incorporate Predetermined and Forecasted Process-Related Experiences into the Supposed Organizational Process Assets

Incorporate predetermined and forecasted process-related work products, measures, and improvement information supposedly derived from planning and performing the process into the organizational process assets, so that the end result is continuation of the activities of the Process and Quality Group.

Typical Work Products
1. Impossibly Irrational Process Improvement Proposals
2. Process lessons learned (again, prepared well in advance and in keeping with the strategy of ensuring continuation of the process and quality group)
3. Manufactured mythical measurements on the organizational process assets (which are sufficiently immeasurable)
4. Impossibly irrational improvement recommendations for the organizational process assets
5. Redundancy filled pages and slides numbering over thousands, comprising of records of the organization's process improvement activities
6. Information on the organizational process assets and impossibly irrational improvements to them

Friday, September 21, 2007

Institutionalising Excellence

Rumela


"Quality" or "Excellence" is something intangible - that results in customer satisfaction or better still customer delight. The software world has seen many models and standards that assure clients of a delivery organisation's commitment to quality. However, there are no dearth of troubled projects even in mature organisations. So how does one go about ensuring delivery excellence in the true spirit ?

I suppose one can either use the reward and/or punishment approach. An analogy with society and the instruments of making people walk on the right path would be

1. Law : Police, Court, Legislation
>> more resource intensive, Cost of Quality is high
>> prime motivation = fear of punishment
>> Quality Assurance & Reviews

2. Religion: Evangelists/Missionaries/Priests/Self Help experts who cite practices, rituals and ceremonies for people to follow
>> prime motivation = desire for the rewards (health, wealth, peace of mind) of practising discipline in daily life
>> Methods, Tools, Processes

3. Philosophy: Self awareness
>> prime motivation = a desire to work for the pleasure of work itself without caring for the result
>> self-motivation, pride in workmanship

If we look at any software delivery organisation, I would associate
# 1 with the SQA function,
#2 with the Software Engineering Process Group function
And as usual # 3 is the tough nut to crack. It is learning and awareness on the part of an invidividual more than Training that is of importance.


And if # 3 is enabled, then automatically # 2 will be practised and # 1 will be needed only on an exception basis.

Saturday, September 15, 2007

Straight from the Gut – The True Story of Estimation

Straight from the Gut – The True Story of Estimation

- Arunabha


“So let’s start,” my sprightly eager young voice, with all of four years of experience in the industry, echoed enthusiastically around the room and died a dismal death as it tried in vain to bounce off the lethargic, pathologically bored countenance of my manager, Shyamal.

We were sitting in the plush conference room of the small, elegant office of my erstwhile firm. The anticlimax of the parochial pastures of Chhattisgarh after the lofty lustre of New York City had not really taken the wind out of my youthful intensity. As I have often realized since, work obtained within the bounds of the country, though lacking in the lure of green-backed dollars, was nonetheless infinitely more satisfying than its onsite counterpart. While I had spent three months in Manhattan, retrofitting an application from one version of COBOL to another, a torture that could not have been tolerated without the magical attractions of a New York summer; the work in the hinterlands of India consisted of architecting a consolidated software system for the Police Department of the state of Chhattisgarh, including neat stuff like GIS/GPS and Case Profiling.
And the big cherry on the cake for me was the process of Estimating for the project that I was supposed to do with Shyamal, a veteran of sixteen years in the industry, who looked on with a lazy, benevolent smile as I fidgeted to unleash my golden nuggets of IFPUG based wisdom on the requirement specifications.

“Okay,” my senior agreed, seeming unable to find even a remotest opportunity to get away, as we sat with a list of systems and subsystems in front of us. “So, the Case Register system. How much would you say? 30 Function Points?”
I winced. “30? How can you say that?”
“How many FP then?” Shyamal asked, accommodating, affable and anxious to get it done as quickly as possible.
I frowned. The long hours of perusal of the IFPUG web site and associated documents rebelled in me. “Let us at least look at the transactions, otherwise how can we say how many FPs it will be?”
I took up an architecture diagram. “So, if this is the application boundary, let’s focus on what the External Inputs are …”
Shyamal chuckled. “You want to do all that?”
“What other way is there?”
He gave in, in an accommodating and avuncular way. I fiddled around with the system diagrams, jotting down the external inputs and external outputs, furiously debating whether something or the other was a query or a report. Shyamal did not really stop me. On the contrary he lent me a helping hand in jotting down all the figures I came up with in an excel sheet, though he did not deign to rename into anything else from Book1.xls. He nodded with that perpetual tolerant smile as I feverishly debated on the number of Data Element Types and File Types Referenced. He even put in an experienced word or two when I tried to figure out whether a system should be a Logical Internal File or an External Interface. And I was grateful when he stepped in and clarified a minor confusion about File Types Referenced.

When I had done the computations, I thought I heard him release a long pent up sigh of relief, which was perhaps re-inhaled as a gasp as I proceeded to work on the fourteen Value Adjustment Factors. However, he was still smiling when I had completed the whole series of computations and was looking on with paternal pride at the Cell AB27 of Book1.xls which gave me the adjusted function point count in red and bold.
“Are you done?” he asked with a fervent glance at his wristwatch. It irked me somewhat. I knew he was quite fastidious about leaving office at six, but we had completed the huge task well ahead of his personal and, in my opinion, selfish deadline. Why was he hurrying along without enjoying the job? I had just done an estimation I was proud of and given a chance I would have liked to pit my calculations against a couple of Estimation Experts from IFPUG and see whether I could hold my own as a member of that elite league.
With a scornful look at my superior, I opened the Baseline Report on the intranet which had the productivity figures. As I scanned the table looking for the Java/Oracle combination, Shyamal entered the Visual Basic/SQL Server figure in Cell AB28.
“Hey, I thought we were supposed to use EJB and JSP and ...”
For the first time Shyamal became a trifle authoritative. “Better to keep the figures low. VB has the highest productivity figure …”
“But, we are not developing this in VB …”
“How does it matter? Do you think the productivity that we finally manage to come up with in this project will be anywhere close to any of the figures in this Baseline?”
“But, Java …”
“You know how productivity figures are computed, don’t you? Does this FP per man hour have any meaning in our organization? Or in any other organization for that matter?” he paused and looked at me. “You had your fun in estimating, didn’t you? Now let’s get down to work. There is more fun on the way…”
Soon, having cast his lethargy away like a shell, he had come up with the costing in Cell AB29. The figure was somewhere around 96 lakhs. For the ones unfamiliar with the Indian system of counting, it is Rs. 9600000. Shyamal smiled to himself and shook his head as he mailed the document across to the Project Director.

“Brace yourself now,” he remarked with a wink as within a couple of minutes our Project Director had made a furious journey from his cubicle and had stormed in to the room.
“Have you guys gone crazy?” he bellowed as the smile I had tried to conjure to my lips to greet him died an ephemeral death. “You call this an estimate?”
Shyamal surprised me with his equanimity. His expression did not lose the laid back demeanour, the cordial smile … in fact the smile became more sympathetic.
“How much are they willing to pay?”
The PD threw his hands about in exasperation.
“TCS will definitely bid sub ten. There’s Infosys in the running too. We definitely have to come up with something under eight.”
“Eight, is it?” Shyamal calmly jotted the figure in a notepad.
“Yes, not a penny more.”
I was finding this complex encrypted language beyond me, especially the last semi Archerian phrase. The units seemed to have been muddled up beyond recognition. However, I thought I had got the gist.
“But, sir, if we need to quote less, we need to cut down on the features …”
“Cut down on the features?” PD bellowed again. “We need each and every feature, believe me … we won’t survive if we cut down features to meet estimates. Heavens, what an idea! TCS will give more …,” he was too worked up to speak any further. “Shyamal, please explain it to the rookie and email me the new estimate in fifteen minutes. I have to send it across by five.”
He stormed out as he had stormed in, having no problem in complying to the tempestuous standards he had set for his locomotion, always working towards continuous improvement.
Shyamal chuckled. “Now we are having fun, aren’t we?”

I looked after the blurred image the PD had left in his wake, a tumultuous bump in the eternal map of space-time – which I have come to recognize in later years as black-holes in the upper echelons of corpo-reality. Slowly I turned towards my senior for guidance.
“What is eight?”
“Eight? You mean as in the number?”
“Yes, I am also getting number by the minute. What on earth is eight? He told us to quote below eight.”
“The very same number. The same one that is between seven and nine,” Shyamal laughed. “Come let’s get this over with.”
“What do you mean? We just came close to 96 lakhs. Do we have to bring our estimates down to eight lakhs?”
“That’s right,” he smiled. “Come, let’s do it …”
I was still struggling with the insanity.
“But, but …”
“It’s simple really. We will divide all the calculated FPs for the different subsystems by 12. That should do it. That’s why I wanted to start with FPs straight away. For the minor adjustments, we can play around with the VAFs.” He was already typing in 12 in cell AB30.
“But, what about the transactions? I mean all the EI, EO, EQ, ILF, EIF …”
Shyamal patted my back.
“No one needs to know. You and I know you did a good job, and it’ll be our little secret. Now let’s forget that and come up with something that will sell.”
“Sell?” I mouthed. I had the sinking feeling of missing something critical. “And what do we do when the client comes back at us and tells us to deliver within …”
“That’s something we’ll consider when we come to it … You’ll get to know the workings from estimates to actuals later. The numbers you came up with were the estimates of estimates, and now by dividing this by 12 we will get the actual estimates … and when we get down to work we will come up with the estimated actuals and whatever will go down in the metrics sheet will be the actual actuals … well it’s sort of complicated.”
“You bet it is,” my head swam.
Shyamal’s smile became broader. “All this will become clearer with experience… But, for now, let’s get down to dividing by the dozen …”