In my post, following a thread created by Craig Brown and developed by Glen Allen, I closed it confessing my difficult to offer a clean definition of what can be defined as “done”. In my mind there is the “Prince2” definition that sounds:

“Everything that has passed the tests based on stately accepted [...]]]>

Where to cut

In my post, following a thread created by Craig Brown and developed by Glen Allen, I closed it confessing my difficult to offer a clean definition of what can be defined as “done”. In my mind there is the “Prince2” definition that sounds:

“Everything that has passed the tests based on stately accepted criteria”.

However, this leaves some room for the human factor. It is true, especially the perception from stakeholders about what can be accepted. Many stakeholders’ categories (graph) have different viewpoints on both terms of features and quality. In particular about:

1. What can be delivered (developers)?
2. What can be accepted (customers)?

The answers could be found in the Glen’s questions and my answers:

1. Can we state clearly and concisely what “done” looks like? Can we state the intermediate versions of “done?” Can we state this in some units of measure meaningful to all the stakeholders?
   • It can be carried through the completion of all required operations, followed by the functional testing of the output. The results, expressed in percentage, state the readiness of the product. In this way all stakeholders can find a common ground.
2. Do we know what it will cost to get to “done” or any smaller version of “done” along the way? This cost is usually measured in money. But people and other resources are part of the answer as well.
   • EVM (properly managed) could measure the ratios between efforts (monetized resources) and results (passed functional tests).
3. Do we know the date of when we’ll see “done” or any part of “done?” What the variance on this date? If we don’t know the date of the final “done,” how about a “date for the date?”
   • At work-package level (team) these evaluations shall be done frequently and openly (involving the customers in clear and friendly terms). At a “higher” level, the “IMS” (major plan) should be based on precise dates (including tolerances).These will supply (together with the WBS and then Product Backlog) the criteria for shaping the gateway destined to evaluate progresses. The terms and conditions each of these processes shall be verified (and confirmed) at each level. In my previous post were described the risks implicit in setting a rigid structure up.
4. Do we know how we will measure progress along the way? How will we have confidence that progress is actually being made? What are the units of measure for this progress?
   • Planning (at project level, leaving details for the work-packages) shall include Risk Management and Test. The definition of capabilities (features) cannot be done without stating clearly what has to be used for measuring them.
5. Can we see what is going to impede our progress toward “done?” Do we have any way to remove these impediments so we can get to “done?”
   • Only if the product is clearly described (at various levels and times) it is possible to manage the production and consequently the outcome.

Conclusion

“You can manage only what you can measure”. This notwistanding the article of his father (DeMarco).

D/load PDF version

Thanks Craig. You got right about the need for frequent and more specialized controls.

By the way, originally “milestones” (in the Roman roads) were set every mile (0.91% of the Imperial mile). Every day-long leg (15-18 miles) there were structures serving both passengers (divided by categories) and animals. An interesting point was that [...]]]>

Titanic in dock

Thanks Craig. You got right about the need for frequent and more specialized controls.

By the way, originally “milestones” (in the Roman roads) were set every mile (0.91% of the Imperial mile). Every day-long leg (15-18 miles) there were structures serving both passengers (divided by categories) and animals. An interesting point was that all measurements were taken starting from just one point.

In essence, all the territory was divided in smaller units for making possible and easy any comparison.

Milestones and BDUF

In many fields, in order to obtain the needed money, customers want to see “detailed” specification both in time and features.

These types of situations needs that controls are set in two different and complementary ways:

1. Consider the check point as a tool for setting guidelines (assuming that big projects span over long periods. Therefore, impending modifications are difficult to be avoided).
2. Once operational details are left to the team, controls have to focus on its capacity to deliver up to the specifications, both in terms of “quality” and “quantity”.

Some organizations, which rely on “functional model”, view in the BDUF a way to reduce risks. This viewpoint obtains a huge increase in threats to the output. A rigid structure is fragile. Titanic offered a terrible example, how a fragile structure was dealing with uncertainties.

For their nature, milestones are there for measuring results.

Any change is a result. Assuming the need for controlling performances for business reasons, there is a list of questions that could help us in the definition of what is measurable (and why):

1. Who decided and approved what shall be measured?
2. When controls should be activated? Where a trade-off between frequency and costs has to be struck)
3. What is the standard value for comparing so different items? For example, analysis and development need different approaches for measuring results. If money, it has to be actualized using parameters that are based on common and shared values)
4. How can we evaluate the stakeholders’ importance (and priorities)? Either in evaluating results vs. committed efforts.
5. Which is the reference for measuring the direction (thinking in terms of polar coordinates)

Some technical concerns

Regarding the analysis, controls can easily verify the business area covered.

Whether the outcome complies with developments and then the business viewpoint or not, is a much more difficult task. The evaluation can be done after the successful execution of functional tests.

At a development level, for customers’ viewpoint the GUI offers much more room for appraisal within shorter periods, than an enterprise business logic or databases developments.

When milestones can be conceived?

In my opinion, they should be produced by a “logical system”, either during the issuing of WBS or Product Backlog. It will be the project’s nature to dictate the frequency and type of milestones. The concept of making them repeatable is a huge bonus. A partial solution could be finding in the automation of the data collection, the rest remains up to each project manager’s ability to deal with stakeholders.

Conclusion

I am conscious that the concept of “done” has been left out from this post. It seems easy to establish rules on pure technical matters. However, it cannot be limited to a checkpoint list (although it is necessary).  “Done” should be enlarged until it includes the idea of “sold”.

“My life is full of mistakes. They’re like pebbles that make a good road.”

More readings

http://svprojectmanagement.com/are-you-organized-for-success

Photo from http://www.nordikfolk.com-a.googlepages.com atitanicstorybymike&ernstulrikpersson  May 4, 2008

Risks (negative and Opportunities as positive) are occurrences of an event that would modify the project’s outcome.

Only when the hypothetical course has been set, it is reasonable to evaluate the possible events that will have an impact on the output.

Each “Option” has different risks. [...]]]>

Like squirrels, reserves are essential

Risks (negative and Opportunities as positive) are occurrences of an event that would modify the project’s outcome.

Only when the hypothetical course has been set, it is reasonable to evaluate the possible events that will have an impact on the output.

Which are the risks’ sources?

Each “Option” has different risks. Deeper the digging into the details, more accurate will be the output. At a Business Case level, everything can only be evaluated at a high level. This requires that attention shall be paid to the possible effects generated by applying the chosen “Option”.
All risks are calculated with the following formula:

Risk = importance x likelihood.

1. The importance’s value is supplied by business vision and confirmed by cost/benefit’s analysis. It is expressed in money (costs and windfalls).
2. The correct amount should be worked out using the method chosen for the “Investment Appraisal” (following section) Capital budgeting.
3. The likelihood is expressed in percentage (100 represents certainty). The input will be supplied by analyses of similar situations. Working in a familiar environment, where the events had formed a history is a huge bonus for the reliability of the “Risk Analysis” (to be considered as a branch of the “Risk Management”).

Finding the correct values

The quality of every analysis depends upon three factors:

1. The reliability of the used formula(s) for retrieving and confirming the incoming data– its acceptance in academia and/or industry.
2. The number (quantity) of data and the correctness of their sources.
3. The intelligibility (and subsequent acceptance) of each risk’s label.

For the Business Case, these three rules can be easily respected.

1. In the logic of using “fractals” for producing the logic that sustains all projects’ documentations, these formulas will be used throughout the whole project. Those features that were considered “important” will receive more attention (i.e. resources). The figures forming the vectors (e.g. significance, costs, stakeholders’ quantity and importance) will be used as input for the formula for building the “Impact Matrix”.
2. The data to be used are coming straightforward from the document itself. This operational condition offers the opportunity of maintaining sound connections between the data used for taking decisions and the criteria adopted for applying them. Giving certainties creates a solid ground for mutual respect and comprehension.
3. The list of projects’ risks offers a broad view of the potential sources. However, managing a diagram composed of five categories for a total of forty-five items it is not an easy task. Furthermore, some categories are fitted for Sponsor (Snr Managers); others are prone to be considered as blames, more than just hypothesis. This does not reduce the importance of each item; the remark is focused on considerate way to propose the risks’ label.

How to present the risks’ impacts

The ubiquitous matrix (where impacts meet likelihood on a Cartesian Plan) offers a good entry point (good site)

However, the power of this tool is a bit overstated. The essential questions about Risk Management are to be focused on resources (people’s commitment and money available)

Who will be responsible for what

Starting from the categorization of the risks, it is obvious that some elements shall be addressed by Senior Manager(s) in conjunction with stakeholders.

How much can be spent

Other as much as important the allocation of budget for a global (administrative) support of the Project Manager, otherwise the outsourcing to external professionals.

Setting the reserves

The money to be put aside, are destined to finance all operations that would be activated if the event occurrence has overcome the threshold value.

Cultivating controls

The system relies on the ability of each person responsible for spotting the increase of danger and understand (at managerial level) the importance and reliability of this signal. People remain the powerhouse of the project.

Fixing the ceiling

Quite often the amount resulting from the matrix (the financial reserves) is astonishing high. It looks like the project is too riskier. The amount to be left as project’s reserve will work as cursor. Only the work-package(s) on production shall be covered . It would be better to close the project, saving what has been done to start with another “Option”, than do not start at all.

Conclusion

The Business Case is produced within a small circle of people: Senior Management, major stakeholders, architect/SME and the PM in charge. Everyone is called to take decisions that will form the guidelines. In situation like these, the quest for accuracy could hamper the process. Otherwise, documenting each proposal offers a solid ground for building the framework.

More readings

http://www.projectsatwork.com/article.cfm?ID=250401
Image courtesy of: http://ahmandishere.blogspot.com/2006/12/squirrel-intentionality.html

D/load PDF version

The project manager is called in for executing a decision taken by the sponsors. The success (respecting the agreed time and budget) depends on whether he/she has enough power (and ability), to act within clearly established boundaries, or suffer from the inability to manage the requests for changes.

The only possible way [...]]]>

Statue of Liberty structure

The project manager is called in for executing a decision taken by the sponsors. The success (respecting the agreed time and budget) depends on whether he/she has enough power (and ability), to act within clearly established boundaries, or suffer from the inability to manage the requests for changes.

The only possible way of fulfill a deed consists in the thorough understanding the motives that designated the target(s).
The “Project Mandate” (an excellent link) should state the “principal” stakeholders’ priorities. These represent the first and most important source for Risk Analysis.  The priorities shall be clearly focused on subjects which are meaningful for the intrinsic nature of the proponent. They will be used to outline the project itself.

The act of planning means to prepare a chain of actions (and responses) in a specific portion of future. Therefore, the available resources can be coordinated with a common logic. They will tune their works for increasing the opportunities to deliver the required result.

The most suited logic is the one that can satisfy the stated priorities. Hence, the core of planning is the ability to define a “visibile” target and then organizing the resources in a way that every involved person can do his/her best for reach the target.

Striking the balance between stakeholders’ pressure and target consistency.

Dealing with the future implies the presence of uncertainties. Therefore, some grade of flexibility shall be introduced.

Without a proper control from the project manager (supported by the senior management) the open-mind attitude will transform the freedom into anarchy. Every stakeholder will feel to entitle to add his/her own modification; often without taking care of discussing the impact on the common target, with the project leader.

The plan’s resiliency shall be adapted to match the needs of different type of stakeholders. Furthermore, it has to evolve progressively in the allotted time.

The stakeholders’ pressure represents the most important aspect of communication. However, there are two dimensions to be considered:

1. The distance, in terms of time, of the event from the starting date. This dictates the granularity of details.
2. The impact of the proposed modification on the plan’s feasibility (Iron Triangle).

The first point (time and details) is about the need for having everything stated on a document. It could be smuggled as professional attitude; in reality, it is a way to hide anxiety. A rigid planning assumes the necessity to tame the future. The project manager has to intervene for understanding the nature these fears. The Risk Management could offer sound answers to this kind of questions.

The second point (changes) involves all stakeholders. For a sake of clarity, in the following list, they are grouped for area of interest:

Technical:

The choice of the architecture (from the type of application/web server down to the nitty-gritty of rules for commenting code) either is a project’s priority, or it shall be left to the small group of experts. They will issue a couple of feasible proposals that have to be fit for the aforementioned priorities. The final decision will be taken by the project board on the company’s needs.
Once the technical proposal has been set, every other decision (e.g. request for change) shall be conformed to it.

Commercial:

This is the most area most sensible to modifications. The simple and strongest reason for this: a weak business case. Whenever the benefits for the business seem insufficient for covering the initial expenses, the project will be laden with new requirements. This is the most expensive and surest way to doom it.

Functional (personal):

As stated Machiavelli (The Prince), there is no difficult task such as bringing innovation into an organization. Who prospers in the old system will be an enemy of the new one. People that will receive benefits, are shy to spend effort for the innovator.
The only working receipt: a constant attention to details. When the time has come to deal with each of them.

Conclusion

“A good plan today is better than a perfect plan tomorrow“.
The plan has to be dynamic. The priorities (well supported by the sponsors) shall form the robust structure, while the single tasks are detailed as soon as the time will be mature.

The Statue of Liberty offers a marvellous example of using a “rigid” structure as kernel, then, by mean of “flexible” bars each piece gains of a good grade of freedom.

More reading:

www.projectsmart.co.uk

For their intrinsic nature, they shall be based on an unbiased communication system that collects the information necessary for evaluating the results of the spent efforts on a specific task. In the [...]]]>

Controls are structured data. They shall be devised to report a specific situation that could influence the output. Therefore reducing the project’s opportunities

For their intrinsic nature, they shall be based on an unbiased communication system that collects the information necessary for evaluating the results of the spent efforts on a specific task.
In the previous post, they were presented as tools to be set up for risks’ mitigation. The hinted solution was about finding a common strategy. One of my favorites quotes from SunTzu is about the best battle is won without fighting. The knowledge of the matter gives enough strength for making profitable alliances. However, due to the complex structure of project’s stakeholders it is not an easy task to sell an idea that fits to everyone.
Two major winning points can be offered:

1. Increase the success’ opportunity through the reduction of uncertainties.
2. Reduce the workload leaving more room for “real” communications.

Finding the right key

The goal is to improve the communication. In theory, this would have no enemies. The implementation of an automatic system for collecting data could be easily built using well designed scripts (e.g. Ant) based on Unit test’s concept (e.g. either for java, php or msdn). This solution will supply a steady flow of information about the quality of produced code. However, everyone has his/her own caveats for implementing any solution based on transparency. This is particularly easy to spot it in the developers, who could resent it as a mean to put pressure on them. The quantity and quality of the produced code is not the only source of risk.

Moreover, this system needs to be fed by data elicited by business analyst from domain experts and users. Hence, the workflow’ complexity will increase.
This is the core of the topic. The costs of implementing controls shall be balanced by the reduction of the risks.

Conclusion

Financial aspects (efforts’ costs) are not the only one to be considered. At stake there is the collaboration of all stakeholders. Risk management needs a holistic approach. Everyone shall be involved in spotting potential weakness. All this kind of information shall be collected in the right occasions, then filtered and made intelligible to the senior management.

This sheds a different light on this matter. At least this introduces logic for setting procedures that cost and, if not properly set, hamper the production. The focus is on the single control. The success of the whole project, where success is the acceptance of the outcome [...]]]>

Juggling with risks

Controls are set to reduce risks

This sheds a different light on this matter. At least this introduces logic for setting procedures that cost and, if not properly set, hamper the production.
The focus is on the single control. The success of the whole project, where success is the acceptance of the outcome from the stakeholders, shall not obliterate the simple fact that some resources designated to check at least one dimension (i.e. scope creeping, time for completing a task, number of mistakes in code) did not work. Either the results did not reach the people responsible for taking the decisions, or these data influenced a wrong determination.
This situation creates some of the following consequences:

1. Those resources were squandered.
2. The human (professional) relationships were tarnished. After that the leadership / trustfulness is lamed.
3. The confidence in the adopted method is reduced. Hence, further resources will be allocated for reviewing the rules. More energy will be spent (wasted?) for convincing people to abide to the company’s standard.

Instead of blaming more or less specific cultural attitudes, the attention shall be moved on the motive(s) that sustained the application of those controls.

Every action has a cost

People (and machineries) that have been made available for completing the project must be held accountable for their action(employment). Does it mean that is it feasible to audit every bit of the people assigned? Forget any though about 1984 novel or Plato’s Republic.
The controls themselves cost; moreover, they are carried out by people. “Quis custodiet ipsos custodes?” “Who watches the watchers?”
The efficiency and the effectiveness of controls depend upon the power (willingness to accept them) used for applying them. Therefore, to work out the required efforts for implementing controls, the management’s energy shall be considered as part of the whole job.
The process of controlling is composed by these elements:

1. The matter to be gauged. This has to include a metric.
2. The performing subject.
3. The target. How much output’s measurement has reached the acceptance’s point?
4. The controller. Who/what read the measurement and then to confirm its validity.
5. The user. Who receive the output and “shall” perform with it.

To set up any control is a daunting project itself. Nevertheless, they are unavoidable. Accepting the assumption that controls are necessary for reducing risks, it is easier to find a common source (denominator) for them.

Conclusion

Controls are just tools for checking the reality. The surrounding world is plenty of signals; however, we are able to pay attention to few of them. Make a stark choice about what is really important helps us to survive. In a complex business environment, like a project, the implementation of a strategy is paramount. To be accepted by all stakeholders, it has to be broad enough for containing, at least a slice of everyone’s interests.