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 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
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
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 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.
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
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 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 https://www.valuetransform.com/downloads/