Details

Written by: Kim

Category: IvyBay Papers and Publications

Published: 02 October 2016

Hits: 5848

• I’ve been managing projects for quite a few years now and have often answered the question ‘Why do we need project management?’ For organizations rambling along without project management the whole discipline can be a little hard to understand. Why do we need a separate person just to keep the project on track? We have managers and implementers already!

Project management is itself a separate discipline. (Many project managers were managers and/or implementers at some point in their careers and opted for the more specialized route of project management.) By implementing project management – which implies but does not require dedicated project managers – tracking, visibility, and projections for a project are all increased. Consider it a combination of an early warning system and a Mom nagging.

Project managers typically report to a part of the organization that can be more impartial than the implementing organization. Good project management processes make it easy to see the assumptions, dependencies, and impacts of a project and components of a project. Dependencies are not only identified but are managed. With a solid project plan the goals of a project are documented, responsibilities amongst the various contributors are established and documented, and each participant can understand how what she or he does affects the project as a whole. Project management typically includes resource monitoring and balancing as part of the whole process.

One of the key responsibilities of a project manager is risk management /risk assessment. The project manager ensures that appropriate contingency is built into the project plan, especially the schedule but also other components. Constant risk assessment is performed, with small adjustments for risk management made as appropriate. Large looming risks are called out in formal risk assessments, including options and recommendations, so the project owner is aware of any potential issues and can make appropriate risk management decisions.

Project managers work early in the project to understand and document the project drivers (schedule, cost/resource, quality, scope) and ensure that the correct tradeoffs are made day to day. They report on project progress to the entire team, including the project owner and stakeholders, on a regular basis so progress can be reviewed and adjustments made as necessary.

Project management focus throughout the project looks like this:

• ·   Establish project goals and drivers
• ·   Document any project level assumptions and dependencies
• ·   Ensure requirements are complete
• ·   Obtain estimates for implementation
• ·   Document dependencies amongst project tasks
• ·   Ensure project is properly resourced
• ·   Establish contingency plans for any substantial risks
• ·   Ensure all processes pertinent to the process are created or located and adhered to throughout the project
• ·   Track day to day progress
• ·   Constant risk assessment
• ·   Make minor adjustment in staffing, requirements, etc., as necessary
• ·   Report status to project team and stakeholders on a regular basis
• ·   Create risk assessment reports as necessary
• ·   Beg, cajole, adjure implementors as necessary to accomplish tasks on time
• ·   Escalate any issues or stalemates as soon as it becomes clear that the team cannot resolve within the current structure
• ·   Trigger contingency actions as necessary
• ·   Ensure smooth release/completion
• ·   Hold post-release review to determine what went well, what could be improved, and set any improvement plans in motion

Generally, most of these activities really do not take place without a focus on the discipline of project management. Project management really does lower risk, raise visibility, and take the burden of day to day tracking and reaction away from team members who are more valuable focusing on their implementation or functional management tasks.

Details

Written by: Kim

Category: IvyBay Papers and Publications

Published: 02 October 2016

Hits: 6840

f you’re building a dam, trying to figure out why the Space Shuttle crashed, or exploring causes of an oil rig fire there is a discipline called Engineering Risk Analysis that has an extremely mathematical basis and rigorous procedure. If on the other hand you’re managing a software project, a marketing roll-out, a construction project or even an event for a school or charity, risk analysis and assessment is a continuous process. Project managers in particular are on the lookout not only for obvious events, but also for trends and decision-making processes that may indicate an increase in risk.

The bulk of this work is in monitoring of current events, situations, and processes and constant evaluation of risk based on these factors as a background activity. Constant small adjustments can be made without fanfare to bring risk anomalies back into line with acceptable parameters; however, when the assessor feels that risk is approaching an unacceptable level closer examination is needed. If the initial indications are borne out (risk is outside acceptable parameters) the assessor should issue a formal Risk Assessment to the appropriate team members and decision makers.

Knowing the parameters:

It’s important for the person assessing risk to have a solid understanding of the project’s (and project sponsor’s or owner’s) risk position. Some projects have a fixed end date (it’s been announced, the venue is booked, etc.); some must adhere to company or governmental codes or specifications; some have a fixed cost. Sometimes the project owner is just very risk-averse and needs to know everything; much more often (and usually much more sensibly) there is some room for movement in some or all of the project dimensions and a rising risk can be easily managed by adjustments in the project or process.

Situations triggering formal risk assessment:

Three primary types of situation trigger a formal risk assessment:

· Current course of action: a current course of action, often based upon a recent decision, has increased risk to the point where it is outside acceptable levels

· Comparison of options: a decision point exists where one of several options must be chosen and an analysis of the risk must be undertaken to show all sides of cost, not just cost of implementation of the option

· Trends: the assessor has observed a trend in behavior or metrics that is escalating risk in some factor of the project or process

How to assess the risk:

The steps to take in performing a risk assessment are fairly straightforward; all costs would be approximations for comparison purposes only:

1. Clearly define the process, project, or action that is causing concern

2. Define goals of process/project/action: Before you can assess the risk of a situation you must understand (and any decision-makers must understand) what is trying to be achieved by the process, project, or action. This is also key to the assessment of risk – if the goal of a process is to shorten schedule time but the current implementation is going to cause a schedule risk an adjustment is clearly necessary.

3. Assess risk of change to any of the four dials: The easiest way to assess risk is to look at each of the four dials and predict whether the activity being assessed will cause a significant change (in the wrong direction) for the parameter. The four dials are these:

· Schedule

· Cost (in people, dollars, other resources)

· Scope

· Quality

4. If multiple options for a course of action to achieve the stated goal are being assessed, determine pros and cons of each and compare the pros, cons, and risks of each.

5. Determine whether any mitigating actions are available to help lower the risk and the cost of each.

6. Note any possible contingencies to be enacted if the projected risk is realized (recovery actions) and the cost of each.

7. Determine recommendations, if any, to be made.

How to report the risk assessment:

Once the assessment is complete it must be communicated to those responsible for making a decision on a course of action. A risk analysis/assessment report should be created with the results of the analysis and issues and sent to (or discussed with)the appropriate stakeholders. The contents of the report may vary depending on the situation that triggered the assessment.

Report Contents– Current course of action

· Overview of course of action

· Current goal

· Current status

· Current risk position

· Current risk factors

· Proposed mitigation steps

· Contingencies

· Recommendations

Report format – Comparison of options

· Overview of need for decision

· Current goal

· Current status

· Risk of delaying selection of option

· For each option:

o Risk factors (4 dials)

o Pros

o Cons

o Implementation cost

o Proposed risk mitigation steps

o Possible contingency plan and cost

· Table comparing options

· Recommendation

Report format – Trend

· Overview of trend

· Current goal

· Current status

· Current risk position

· Current risk factors

· Proposed mitigation steps

· Contingencies

· Recommendations

And then what?

With any luck the project owner will determine a course of action based on the recommendations made in the report, including implementation of mitigation steps. No change is still a decision – if it’s communicated. After issuing the report follow up until you have determined that the owner/sponsor/stakeholders have actually read the report and understand its contents, and ask whether they would like to take any action at this time. Once you receive an answer, proceed with the course of action as decided.

If the project owner did not want to change course be sure to report regularly on the risk and any risk mitigation actions being taken. If the risk mitigation doesn’t work (i.e., something bad happens as predicted), unless there was specific feedback indicating that the contingency plans were not acceptable, announce that the contingency plans will be put in motion and remind everyone of any associated costs. In this way the project owner is kept aware of the risk, mitigation steps, and contingency plans and should be ready to pull the trigger on them. Be sure to continue reporting until the risk (or resulting situation) is contained.

Details

Written by: Kim

Category: IvyBay Papers and Publications

Published: 02 October 2016

Hits: 6221

Background:

Every project has four dimensions that can be managed.  Each of these dimensions can and should have associated goals, and the list of dimensions must be prioritized as well.

The Dimensions:

1. Scope:  For software projects, scope is the project requirements list.  Typically, this includes performance requirements and a set of features.  To increase the scope, add features or make existing features on the list; to decrease the scope, remove or simplify features or reduce performance requirements.
2. Cost:  For software projects, cost is primarily contained in resources needed for the project.
3. Schedule:  The schedule for software projects is typically prioritized using the desired release date.  If interim dates (alpha, beta, feature freeze, code freeze, etc.) are determining factors, these dates may be prioritized separately.
4. Quality:  Many models prioritize based on the previous three dimensions only.  Unfortunately, what usually drops is the quality of the product  or at least the testing time.  It is important to realize that the quality of a software product is directly influenced by the other project dimensions.  There are times when the product quality is of lesser importance than other dimensions – demo deadlines, marketing events, etc. 

Why prioritize?

It's true, of course, that all four dimensions are critical to a project.

Think of each of the dimensions as a dial.  On any project, the project sponsor can 'set' any two of the dials.  Those two dials guide the project, and don't move.  The other dials can be turned as goals, but they move in order to allow the two guiding dimensions to remain set.

Trying to set more than two dials almost always causes at least one dimension to fail to meet expectations.  The problem is that there is no control on which dimensions fail – things just start falling through the cracks. Although determining the priority of the dimensions can be a difficult exercise, it enables the project sponsor to maintain control and provides guidance to all project team members throughout the project in making day-to-day trade-offs.

Throughout the Project:

Any significant movement in any of the dials does trigger a risk assessment during the course of the project.  Prioritizing the dimensions does not mean that the 'unset' dials are ignored; it simply means that the project team understands the priorities of the project sponsor when trade-offs must be made.

Project Name:   _______________________________________________

Project Sponsor:  ______________________________________________

Date:  ____________________

Check Two Dials:

____ Scope              ____ Schedule            ____ Cost/Resources           ____ Quality

Details on the dials – Settings for top two, goals for others:

Scope:         (note specific features/items or date and name of document)

Schedule:    (note phase and date)

Cost/Resources:

Quality:     (Note test time/cycles,  bug metrics, other)

Details

Written by: Kim

Category: IvyBay Papers and Publications

Published: 02 October 2016

Hits: 6135

What

Every software company needs to be able to tell where they are in a development cycle.  Understanding progress and being able to make decisions quickly and accurately are key to bringing a product to market in the right timeframe at the right level of quality.  For small projects or small teams, it is often possible to accomplish this type of tracking without a professional project manager and with very simple tools.

Why

For each project (and amongst projects) the company needs to understand, set, and communicate priorities of products, features, cost, quality, and schedule.  Without this understanding, no foundation exists upon which to make decisions – the only alternative is ad-hoc decision-making, which generally does not take into account any but the most immediate factors and alternatives.

Progress on a given project must be understood and communicated in order to understand when decisions and trade-offs must be made.  Typically, decisions and trade-offs based on project status need to be made quickly as well as accurately; project status needs to be well and easily understood to make these decisions and trade-offs effectively.  There should be no surprises – slips should happen only with warning.

Finally, it’s vitally important to understand when a shift in resources – people, equipment, etc. – needs to be made in order to keep a project on track.  Without adequate project status, it can be extremely difficult to recognize this need in time to respond quickly and effectively.

How

For relatively straightforward projects with minimal interdependencies, it is not necessary to acquire the services of a project manager, to use Microsoft Project, or to implement many of the other complexities of professional project management.  The keys are planning, communication, and follow-through.

Planning

·         Involve as many team members as practical in each step of the project.  In this way, there will be a more thorough understanding of any issues, more creative ideas will be generated throughout the process, and the team will be buy into the results.  Be sure to include the extended team – representatives from QA, Support, Tech Pubs, and Product Management as well as development, CM, database, etc.

·         Understand the parameters and trade-offs of the project.  The first step is to understand and set the traditional ‘4 dials’:  features/functionality, schedule, cost/resources, and quality.  Typically, only two of these dials can be set. If an attempt is made to fix all four, agility and the ability to make trade-offs will be lost.  At least one of the four factors will suffer, but it will happen by default - without the chance to make choice. The factor that most often suffers is quality.  Goals should be set for all four factors, but the relative priority of each must be recognized.

·         Know when the project will be done.  Set the project parameters.  If using agile practices, for instance, this will be determined for each iteration, but the product ship should still have minimum ship goals defined.  These goals can change if and when market conditions change, but the company should know its goals.

·         Break the project down into the smallest pieces that make sense.  The biggest tasks that are at all manageable are at the feature level; if possible, break down into the module level for development, the test run for QA, and the chapter for documentation.  Track at the most detailed level that makes sense, but don’t break things down just for the sake of breaking them down – that will cause unnecessary work in tracking.  A good rule of thumb is that no single task should be more than one week in duration at the absolute maximum – if there is a single task that takes more than a week, try to break it into smaller pieces.

·         Once the project is broken down, estimate the time it will take to complete each task.  Sometimes this will be very imprecise – some tasks just can’t be well-defined until others are complete.  Recognize that this is the case, take a best guess, and create a task to generate a better estimate when conditions are correct.

·         If there are any dependencies between tasks – one has to be done before another can be started, or two must start together or finish together – capture the dependencies.

·         Create a schedule based on the estimates, taking the dependencies into account.

·         Build some contingency into the schedule.  For the remainder of the project focus on the scheduled completion date, but know that contingency can be used if needed.  In the unlikely case that the contingency isn’t used, the product can ship early or can receive more extensive testing.

·         Assign resources for any tasks that require special skills. 

·         Make a first-pass attempt to assign the remainder of the tasks to determine whether the company has enough people with the right skills to complete the project.  Assuming that the people are available, consider the first week or two of task assignments fixed and understand that assignment for later tasks will probably move as they get closer.  This is a good thing – it provides flexibility in the schedule.  The unexpected will happen and the company needs the ability to react.

Communication

• The easiest and most effective way to communicate the project schedule is to put it on a reserved whiteboard where everyone can see it.  (Agile practices often use posted index cards.)  This makes for an easy way to update the schedule.  Everyone can see it, and people can mark their own tasks complete.
• Keep a rolling list of tasks due for each week.  Post it or send it out daily to remind folks – that way when someone finishes something they’ll communicate it.  This will also make clear when tasks are not completed on schedule, allowing management to shift resources if possible.  When the list is sent, be sure to note when tasks are completed.  We all need recognition of our accomplishments, and this is an easy and effective way to help build your team.
• If any changes or decisions are made, send the information out to the entire extended team in email.  Feedback will be generated immediately so adjustments can be made.
• Keep a running list of issues and decisions.  Sometimes issues will turn up that can’t be resolved until later in the project, sometimes issues will take some time to resolve.  Keep the entire list, including the resolution to past issues.  Never revisit decisions unless new information comes to light – the running list of issues will help remind the team of decisions made previously.

Follow-Through

• Update the whiteboard at least weekly.  If the schedule starts going past the end date- or into the contingency time - make the appropriate decisions to adjust the four ‘dials’.  If you gain or lose resources, the schedule will also have to be updated.
• Have a meeting at least once a week somewhere in the vicinity of the whiteboard to communicate schedule, problems, and victories among the team.  This is an excellent time to review the rolling week schedule, make any updates to the plan, and revise the whiteboard schedule.
• Be sure to have a party when the project is complete.  Celebrating victories is key to good project management.