Getting Good Enough In software there is a refrain of "good enough" started most likely by Cem Kaner of software testing fame. Projects can be good enough as well. The problem is to be able to define good enough in a way that everyone - solution team, project manager, upper management, and the customers - agree that good enough has been defined and achieved at project's end. This is done in the early stages of the project by the business analyst if there is one or the project manager.

It is a simple process. Once the problem is defined with the business there are three questions to ask the sponsor or problem owner or customer, whoever you are dealing with having the authority to answer the questions:
Is this the problem you want to have solved?
How are you going to know you solved it?
What do you need to see to prove to you that we solved the problem?
The answers to these questions are not difficult and constitute the acceptance criteria for the project. The answers also create an informal contract between the project team and the customer: when you show me that the problem is solved, I will sign off.

The answer to question one confirms that the project is tackling the right problem, the solution of which the customer or sponsor is willing to pay.

The answer to question two establishes the acceptance criteria that proves the problem has been solved to the sponsor's satisfaction.

The answer to question three establishes the acceptance test structure - what we are going to do to show the sponsor that we have successfully accomplished the answer to question two.

Getting the answers up front before development has started keeps all the "how hard would it be to..." and other addenda from sneaking into the acceptance criteria. The acceptance is focused on solving the problem as stated and that is all.

And that is good enough.  ¶ 6:25 AM 0 comments

  Agile Planning For some, the agile movement represents an anarchistic reactionary approach to software development and management in general. They see no discernible planning process and cite the Agile Manifesto's statement that "responding to change" is preferable to "following a plan". The Manifesto and related materials say nothing about rejecting planning, only that the plan must be flexible and responsive. In Extreme Programming, a method endorsing self-organizing teams without project management, with the focus on such rapid development of software deliverables that planning seems to be a detriment, each iteration begins with what is called the "Planning Game" in which developers and customer meet to plan what is going to happen in the next iteration. In fact, all of the agile methods include as part of the process a planning session. The primary difference between the agile approach and traditional project management is that the agile approaches all include the entire team and the customer in the development of the plan, and most methods make that plan publicly viewable. All project management approaches state that the plan is a document that proves that planning has been done, and it is not written in stone. Upper Level Management wants the control and comfort of seeing a plan followed exactly and without variation. This is an issue of upper management, not the PMBOK or agile methods. Agile approaches simply state clearly and loudly that plans change. The methods make that change part of the process. Change is forced with every iteration or sprint completion whether successful or not. Upper Management buying in to an agile approach accepts the environment of constant change and realizes that an iterative, incremental approach to project management is the only way to accommodate that change.  ¶ 4:51 AM 0 comments

  Taking task of risks Many project managers perform a risk evaluation of their project in accordance with the best practices of the PMBOK. They dutifully record the potential risks to the success of the project: what might cause the project to miss its deadline, what might cause the project to overrun its budget, and what might stand in the way of the project achieving its stated goals. This is good, but may not be enough.
Over and above the success of the project there is a risk to the organization in running the project. The first risk to evaluate is what is the risk to the organization of not delivering the product resulting from the project? Knowing the overall risk to the organization provides an additional motivation to the whole project. On the other hand, if the risk is minimal or non-existent, you may be leading a project that has a low priority and will thereby be at risk itself.
What is the risk of successfully executing the project? This is a way of evaluating the impacts a successful implementation will have on other areas of the organization. The project may be successful but cause an unforeseen organizational impact. Again, knowing that impact up front might result in a different approach to the execution of the project.
By simply evaluating the overall risks of the project to the organization helps you understand where the project fits in the scheme of things which gives you information about the importance of the project and its priority and dependencies.
Once you and your team has that understanding, the evaluation of risk to the project itself flows easier.  ¶ 10:20 AM 0 comments