Archive for April, 2016

Really, Eliminate Configuration Management?

Anybody that believes they are saving project time, engineering time and money by eliminating configuration management does not understand how things really work. This is especially true if the items you are eliminating the configuration management for, interface with other items. Building a system or subsystems that comprise a variety of software components to which there is no configuration management (traceability) is reckless and will prove either very costly or dangerous. When you are unable to trace a particular iteration of a number of iterations in a number of different modules that comprise a subsystem or system, you will spend far more than a few hours debugging and determining root cause and subsequent corrective action. The test department’s work will be much greater and require more hours than the trifle you are saving in the development work. In fact, the farther the product moves from the developers, the more costly the problem and longer in duration to obtain resolution.

After you feel the burn of this questionable configuration management decision, perhaps it will be time to learn just what it is and does.

New Configuration Management book

Configuration Management and System Thinking

This is an example of non-systems thinking, because it saves the developers a few hours, does not mean it is the best solution to be foisted on the other parts of the organization.

CMMI Requirements Management

We decided to continue with requirements management since there are some generic goals that are probably just as important as the previously discussed specific goal and practices. This is especially true when we consider the long-term impact on our project execution capabilities.

CMMI Generic Goals

The generic goals associated with requirements management are met when we inculcate our requirements management approach within our organization at large. To do this we must first create an approach or set of processes we believe will continuously allow our projects and our organization to reach or even exceed the operational goals. This requires so much more than a brief response to some trauma, or slogans. I have seen organizations fail, even when on the right track due to lack of continuous application and follow through. Institutionalizing the approach to the work means getting people to know what needs to be done using the organization’s constantly expected approach. This offers some measure of repeatability. To do this means our management must act consistently. We cannot say perform against one set of standards today, but tomorrow perform to another set of standards.

Constant and Consistent Application

I am a fan of the show Aircraft Disasters for the root cause analysis work that is demonstrated. This show appeals to the engineer in me. If you watch long enough, you will notice a number of these failures are the consequence of not performing according to a defined process. A jet takes off with low tire pressure on a hot day – knowing that the tires were low – a violation of the process, and ends poorly. That is not to say that every violation of a process results in catastrophe, but unless you think about what you are violating, how will you know. I am sure those mechanics that omitted some steps in adjusting the cables for the elevators did not have any idea how skipping that step would end.

CMMI and Project Management

There are intersections between Capability Maturity Model Integration (CMMI) and project management beyond the specific or obvious project management areas listed below in the staged representation:

Project Planning is Level 2

Project Monitoring and Control Level 2

Risk Management Level 3

Quantitative Project Management Level 5

There are other non-obvious intersections between CMMI and project management. Consider requirements management and requirements development for example. We submit that CMMI makes project management easier. Let us first look at requirements management and the connection to project management.

Requirements Management

This is a set of processes (in staged representation level 2) that we will use to evoke and understand the customer needs. These are in level 2 because these are fundamental to success. The specific goal is to ensure the requirements are managed and inconsistencies between project plans and work products are identified [CMMI]. Requirements are the detailed incarnation of the project scope. Poor requirements understanding will mean poor translation from the project scope from the detailed expectation from the customer. There is more to this than evoking the requirements as there are 5 associated specific practices with level 2[1]:

Obtain an Understanding of Requirements

Obtain Commitment to the Requirements

Manage Changes to the Requirements

Maintain Bidirectional Traceability of the Requirements

Identify Inconsistencies between Project Work and Requirements

The need for obtaining and understanding of the customer requirements is probably fairly well understood by project managers. This is essentially the evoking of the scope of the project and decomposing that scope to the actions and objectives that would be required to achieve that objective. The need for commitment to the requirements is also fairly well understood, this provides the company backing to bring the customer expectations to fruition. Anybody that has been in project management for long understands that unmanaged changes to the requirements can spell disaster for a project. Along with the changes is the ability to trace the detailed requirements back to the customer demands and vice-versa. Experience suggests these two (items 4 and 5) are a significant source of failures in project management. Change is not bad and is to be expected in conventional projects. Unmanaged change is not good no matter the project methodology. The ability to manage changes, and to trace the to level customer requirements to the details of the scope as a result of the decomposition of the customer demand, enables the last item, identify inconsistencies between project work and requirements. If we can match each specific or detailed requirement to a specific customer expectation that is part of the scope, we then know what to de-content when we realize we have to reduce the scope to meet the customer schedule or cost targets. This traceability will also play a role in the project closure work as we verify the scope has been met as part of our contractual obligations. To verify the scope has been met, you must know how the detailed parts connect to the customer demand and then find a way to prove that delivery has happened.

All of these are fundamental to project success. Failure in any of these 5 requirements management items will reduce our probability of project success. The failure will result in project cost and schedule overrun, project contract closure difficulty, and certainly customer dissatisfaction. Therefore, an organization that has reached a maturity level regarding these attributes and able to consistently manage the quality of this outcome will have a significant positive impact on the project results.

Documentation and Rework

Once, a long time ago, I worked at a company that was having some difficulty coordinating their development work. The product that was produced was a complex arrangement of mechanical and electrical / electronic systems. The company was ISO certified and had documentation describing how they would work, including configuration and change management. Funny thing, though this company shows major signs of a configuration and change managements system that routinely does not work. For example, a previously agreed upon solution iteration constituent parts show up, and the parts are then put together to make the product. However, the parts do not fit together and obstruct other parts in the system. The typical symptoms look like:

extensive and costly rework over the interfaces represented by the departments

extensive and costly rework at supplier at the last minute

inability to put sub-systems together to make the entire system function

Documentation and Organization Performance

When we take this to the person in charge of the ISO processes, they indicate there isa configuration and change management process defined and that it is followed. We provide him with the evidence to the contrary and once again cite the documentation. Yet the evidence, multiple geometric collisions with parts that were designed to fit together and costly rework tothe contrary. To quote the Grateful Dead, it’s even worse than it appears since each of the subsystem developers model their subsystems in CAD in a way that would allow the constituent parts to be put together allowing a virtual vetting of the system. In other words, we should have few surprises when we put the parts together – yet here we are with plenty of rework. The problem; the models are not updated, and during virtual builds some aspects or portions of the models are not included in the build. This provides yet another example of a good tool not used appropriately and providing a false sense of security.

Documentation and Work Instructions

Work instructions do not mean the process is performed as your paper documentation says it should be. Rules and processes don’t keep you from doing what you want to do; rather, they keep you doing what you need to do or should do. Management is complicit in these acts because a lack of regimen means it is possible to deliver hurdle free and quickly. Never mind that the delivery is impaired, frequently missing key features, or over cost and has post-launch quality problems. I am sure that is what happened in the health care website boondoggle. By the way, this is not only true for IT and agile, but it is also true for conventional project management as some companies turn their nose up to a by the book approach and cut many corners then wonder why quality is poor, costly rework and late deliveries and there are numerous expensive campaigns and recalls.

Risk Management and FMEA Approach

We walk through the use of the Failure Mode Effects Analysis (FMEA) tool used as a risk register that we can use for our project risk management. Using this approach we can uncover, assess, and plan our risk response actions in one sheet. That includes identify our control or mitigating actions and ascertain the amount of influence or degradation of risk has theoretically happened as a result of our work. The tool is also set up with specific metric and values to identify when the risk is imminent, and a specific person to monitor this particular risk as we know if everybody is responsible, then nobody is responsible. There is even a column for the monitoring.

Imagine you are an executive and you are sitting down to your early morning breakfast with the daily paper. As you read the paper, you find an article about your company and you are stunned to find it is not a flattering article but a description of a traumatic event that has come to a customer using your product. You are shocked and embarrassed and it is not even 0600 yet.

When you get back to the office, you find out this situation was known by the line management and workers of the company. They have been wrestling with whether the problem is, in fact, a problem and the magnitude of the problem if it is a legitimate event. The line personnel wants to determine if it is a problem how to correct rather than make this situation aware and bring the entire company’s resources to bear on the problem. I have seen this situation a number of times and it fits the product development chicken description. However, there are other reasons for a problem internal to the company at the lower levels to be found ultimately by the customer and to the surprise of the CEO. Some of those are:

insufficient root-cause analysis skills throughout the organization

insufficient communications across the organization

an organization culture of wait and see (do not escalate)

organization politics

The organization’s culture does not change quickly, and once we have driven our teams to behave in a particular way, it can be time-consuming and difficult to alter that way of working. Once our people think it is better to keep things on the QT rather than make the situation aware at large, we can expect this way of handling situations that are tenuous to be consistent. It is no wonder that executives find the bad things in the newspaper, or certain engine manufacturers are blaming the failure to meet emissions targets are the result of rogue engineers. Line managers have a responsibility to understand the potential consequences and articulate these as quickly as possible to throughout the organization rather than a wait and see or kowtow to political aspects.

As long as we put our collective head in the sand when we should be boldly and aggressively seeking these possible failures to quickly find a definitive resolution, we can expect to see these “surprises” continue to happen.

I want to start off by saying; I am not affiliated with any political party. There are some key principles by which I behave, but I do not think any one party has a monopoly on good. In fact, if anything, I believe both parties have a monopoly on bad. I also know the book, Audacity of Hope, is not a new introduction, however, for some reason, this title has stuck in my head today and has me thinking.

I have long held hoping in low regard. Hope is okay, but only when linked with doing all that you can do. I have seen hope used in project management and product development as if it were going to come or our rescue, which invariably it does not. Hope allows me to sit in my lazy boy and contemplate winning the lottery. However, to actually win, I have to get up out of my lounge chair and take some action – purchase a lottery ticket, but even that is a long shot to achieving my financial objectives. Hope is a reason for inaction. I hope to live long, but I do not exercise. Hope in itself is inaction.

How then can there be audacity of hope? Audacity, the meaning “willingness to take bold risks[1]” requires an action to be taken. Hope has no connection to action other than by desire. It takes much more than the desire to make something happen. I desire to have a full head of hair, but sadly that is not the way things worked out for me. Hope is a catalyst at best, and as experience suggests an excuse for inaction or our desire to have our wants satisfied by random chance.

I mean no disrespect to the president, then the congressman for the title of their book. I only think hope will get you nowhere. Hoping and wishing are equal and neither of these will solve your problems. Something must be connected with that hope and that is hard work, persistence, constant learning and many other action-oriented words. If hope is your bold action, you may just get that for which you’ve worked – NOTHING. The title might better read Audacity born out of Hope.

In the purchasing contract with a tier one supplier, the expected the “0-kilometer” quality or failure rate is not to exceed 500 parts per million (ppm). These are failures seen before the product leaves the OEM manufacturing floor requiring product rework on the assembly line or as the vehicle rolled off the end of the assembly line. The contract is signed and the development staff sets about developing the product. The design is set, there are trial production runs and run at rates and 18-24 months later the product is coming off the end of the OEM manufacturing line at production volumes.

Shortly after production start, the OEM notices the quality is not consistent with contractual obligations of 500 ppm. A dissection of the product and conversation with the supplier finds that there is one component, had a failure rate of 500 ppm, and there are at least two of these components and sometimes three in the product. Meaning the best failure rate will be somewhere between 1000 – 1500 ppm just for this one component, that does not include any other failure opportunities.

The purchasing objective and the engineering design quality targets were incongruent. We will write more on how this was uncovered later, but for now, we should note that purchasing contract and the technical documentation of the product did not match. There was no way the purchasing and manufacturing objective could be met with this design. This quality problem was foreseeable and able to mathematically calculate. It could have easily been discovered in an effective design review. The supplier of the subassemblies to the tier one knew their part quality and readily divulged that the failure rate for ONE their parts would be at least 500ppm, and the final product had two at least, and 30% of the time it had three.

A connection between purchasing and development does not end when the contract is signed. Nor do these conversations only happen when the cost of the project or product increase. It is difficult to keep each entity’s priorities in focus when the relationship ends at contract signing. Purchasing and manufacturing should have been part of design reviews and discussions with the supplier beyond product cost and delivery dates. Of course, that is all well and good to say after the fact. But that is the point isn’t it? We do not get better unless we critique our past performance.

I have been spending time with many companies online job applications. I have to say, these online job application tools run the gamut in capability. What I have also discovered is there seem to be bugs or defects in many of them. I wonder if the products were tested in a multitude of platforms and my system was missed. I would think Google Chrome would have been one of the test systems. One had the ability to delete work experiences, except you could only delete one, and when you selected the delete for another – nothing happened, though the screen refreshed as if it did.

Some of the things I am finding may not be bugs but requirements issues. For example, on more than one website, the salary was a required input and it was only numeric. The problem with this, I am not a big fan of talking about fixed number for salary up front, and at one time it was advised not to do. Personally, the salary depends upon many other things, such as time off, the scope of work, career growth, the number of hours per week expected, and the benefits package. I would prefer this data entry field to either accept a range of salaries, or better yet, offer up the alpha approach of “negotiable” since for me, and probably a good number of other people this is the preferred answer.

Here is are a couple of suggestions, check your web application as in perhaps more aggressive testing, and perhaps do not for a salary discussion with many other important attributes about the job are not known to really be able to answer.