In this series on CMMI (capability maturity model integration) and requirements, we have discussed: understanding requirements commitment to the requirements control changes to requirements traceability of requirements from detail to scope and back inconsistencies, the difference between of what is included and what is being done The processes above work together and amount to managing the […]
This area of CMMI requirements management has big implications on the project. Experience suggests project managers can get lost in the minutia of the work, but that is the connection to the project. The reason we have taken on the project is to produce some result that is defined (or it should be) in the requirements. […]
We will continue our review of CMMI and requirements management practices. As we have seen in the earlier posts, managing the requirements is necessary for efficient development and doing so has positive impacts on the project as well. Specifically, the project benefits when the organization stands behind attaining the requirements, and is in for a […]
If commitment to the requirements is a significant source of failure, it is followed close behind by the management of changes or additional requirements that come from doing the work. Though many project managers may believe that once a project is underway, there shall be no changes; that is a myopic approach. Change happens. As […]
Knowing and Committing to Requirements Once we have identified and understood the requirements, we then must gain organizational support for delivering to meet the customer demand. It does not matter if we are a supplier or taking on a project internal to our company, we will need people to stand behind the endeavor – commitment. […]
CMMI and Understanding Requirements We have recently been involved in a LinkedIn discussion about understanding requirements. We have had several quick blog posts on requirements over the years. For example, we have written about the connection of requirements and project management. We have also discussed how requirements grow over the course of the development of […]
I have a mental exercise for you project management type people out there. In this exercise, we are going to explore the possible interactions and results of the various knowledge management areas as defined by the Project Management Institute or PMI. In this exercise, we will start with an Ishikawa or fishbone diagram. In this […]
I recently taught a class in preparation for the Project Management Institute, Project Management Professional certification exam. We were going through example questions and the verbiage was very specific and pointed to a specific answer from the four choices available. When the answer was not what was selected there was an obvious level of disappointment […]
This post was inspired by David Greer who presented us with the topic of devops and continuous delirium. When it comes to devops, continuous delirium has two connotations as in wildly excited, and incoherent and bewildering. When done appropriately, the development personnel and our customer will be wildly excited to be a part of such a wonderful […]
Continuous Deliver and Embedded Automotive I have worked on projects that employed continuous delivery for embedded products. The embedded product was an automotive component. The core of the software (the operating system) was specified using conventional approach. This operating system consisted of the maximum model requirements for this globally used component. The component looked and […]