Project, Metrics, and Risks

Project Delivery, or Is It?

You are working on a project.  You have a documentation delivery expected from a part of the organization today, yet you have not heard from those expected to produce a specification document, so you send an email wondering where things are, and let the team know that you need the said document to by 3:00 pm.  The specification arrives at the appointed time, and you pour over it to see what you have.  You are the project manager and not the subject matter expert that would be required to heavily critique the specification.  However, as you move through the document you find something interesting.  In general, the numeric designators for the chapters, sections, and subsections are hierarchical as below:

1 1.1. 1.1.1.

However, as you work your way through the material you notice a set of sections that look like:

9 9.1. 9.1.1. 9.1.1. 9.1.1.

This is in the released version of … Continue reading

Project Closure

Project Closure and Team Disband

One of my favorites and often poorly executed part of a project is the project closure.  Project closure is not just a simple wipe our hands together and smile, then proclaim that we are finished with the project. It is not even handing the customer our results and patting everybody on the back – and on to our congratulatory soda.  The roots of the closure of the project happen in the very beginning of the project when we establish the scope of the project.  If we are under contract the seeds we sow in the contract will be the harvest we reap during contract closure.

Project Contract Closure

To effectively close the project out, we need to have identified the project scope in a tangible way.  That requires a way of tracing the top level scope (customer expectation) to the details of the project, which in the product development world, is typically contained in the … Continue reading

Another proposal to Eliminate Configuration Management

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 … Continue reading

CMMI, Requirements Management, Project Management

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 … Continue reading

CMMI makes Project Management Easier – Scope

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 … Continue reading

But our ISO Documentation Says…..

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 … Continue reading

Risk Management and FMEA Tool Example

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.

The template is a downloadable and is found by clicking this link


Subscribe to our Newsletter

Subscribe to our Newsletter
Email *
Single Sign On provided by vBSSO