Posts Tagged
‘project management’

  This question was posed by Tom Cagley on Twitter.  At first blush these may seem at odds or exclusionary, but perhaps not.  I know why it may seem difficult to be innovative while we are hyper-focused on continuous improvement activities.  A company that focuses on continuous improvement that tends to be incremental can occlude […]

This blog post originates from Capers Jones LinkedIn comments about toxic requirements.  He posted a comment to a requirements article and brought up bloated requirements and toxic requirements.  I have never heard of the name “toxic requirements” perhaps that is uniquely Capers Jones identifier – I like it.  However, I believe I have experienced toxic […]

Our project must balance the input from a myriad of people that are associated and contribute to the project, along with those funding the project to be successful.   To be able to do this, we will need to understand our stakeholders and their perspective.  Some of our the stakeholders will add requirements, support existing […]

Requirements Language As we collect requirements we are going to need to perform some sort of evaluation.  We know the attributes of good requirements, now we will compare those attributes against the documented requirements.  However, we will not stop our evaluation at the type of language. We will extend this evaluation to other areas that […]

You do not have to go it alone when it comes to developing requirements. There are many templates and well-defined approaches to help in this regard.  If you are developing a complex system, it is good to break the requirements up, starting at the highest level of abstraction.  We will call that systems specification.  The […]

In keeping with our requirements work, we will start by identifying the attributes of a good requirement.  We start our project off with the requirements, so it stands to reason if we start off poorly or in the wrong direction, we will not make the objective.  This situation will get worse the longer we spend […]

Technical documentation serves as a repeatable communications medium. That is, written so that anybody reading with the appropriate competency will come away with the same conclusion.  Not filling this gap or relying upon verbal communications has great limitations. Many of us have likely played that game as children where a group of people line up […]

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.  […]