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.
Commitment is more Difficult than it seems
Experience suggests commitment is more difficult than it looks. Organizations make the commitment often without really understanding what that means, or knowing the present level of commitment to which they are presently subjected. The result is an over-taxing or more hours booked than available talent and resources. Additionally, it is difficult to make the commitment for the individual, even when we assign that talent to the project. In other words, having the talent assigned to the project is not the same thing as having the talent and resources committed to the project. In the model we can expect … Continue reading
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 the product. We have also reviewed the connection between requirements and testing of the product. There is more to testing than to requirements, but at least a portion of the testing should compare the product against the requirements. Those blog posts were just a quick demonstration to help show project managers how this process area and the specific organizations capability can help or hinder the project progress. Not only hinder but put the project at risk altogether of being able to achieve the objectives of the project.
Disparaging Requirements is NOT the Road to Success
The LinkedIn conversation spoke of requirements in … Continue reading
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 exercise, we will label the diagram differently than the typical 5 or 6 M approach. For this exercise, we will label the diagram with the 10 knowledge management areas:
Integration Management Scope Management Time Management Cost Management Quality Management Human Resource Management Communications Management Risk Management Procurement Management Stakeholder Management
Now, visualize a project management failure, and put it at the head of the Ishikawa diagram as the symptom for which you want to uncover the reasons, for example, late delivery to the schedule as the symptom. Now see how many of items you can generate, at least … Continue reading
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 from at least one of the participants regarding the words in the question and answers. The words used in the questions were very specific and provided clues to the answers based upon the terminology as the basis for the certification. Meaning, the words have very specific meaning, even outside of the project management context. However, to ensure we all know what we mean when we say things, a common dictionary can help. The term “process group” should bring very specific things to the forefront of your mind, and this is different than the word process. The reason for this specific language is to facilitate communication and … Continue reading
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 and productive project. When done poorly or inappropriately, our work resembles a sense of random and non-sequitur moments that leave the team and customer feeling like they have been thumped on the head.
Constant Builds and Poor Configuration Management
Constant builds of software with insufficient configuration and build management leaves everybody bewildered and wondering about the build and the constituent parts that actually comprise the build, not just what we suppose it to be. Defects come, then are solved and in a subsequent build we find a defect very similar to the previous defect. Upon investigation, we will find that it is, in … Continue reading
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 acted differently depending upon market segment and geographic location, for example, there were two different European incarnations and more than two for the markets of the United States. This was not just some parameter setting or configuration differences, but whole scale differences in feature content and manner of execution.
As we indicated, the operating system, though we called it an execution engine, was specified and developed using an incremental approach. This incremental approach was based upon a prioritized set of features. That prioritization was based on what it would take to produce a vehicle that would operate safely allowing for testing of key features. In the … Continue reading
Learning and Morbidity & Mortality
I have been watching a hospital type show. That show demonstrated something called a Morbidity and Mortality (M&M) Conference and it occurred to me that some adaptation of this approach would help organizations to bring the learning from the work to the entire company.
Learning and Conventional Projects
We have written considerable on the learning organization and how to distribute what is learned throughout the organization. Writing down lessons learned in books, as conventional project management describes, is only so successful. Recovery of those lesson gems can be difficult requiring somebody to read a multitude of lessons that do not apply before stumbling on that piece of jade or diamond that may help. We can make this easier if we have digitized our lessons learned book. However, we really still have the same problem even if we make use of metadata and tags to help the search.
Learning and Agile
The agile approach to … Continue reading