Wednesday, April 18, 2012

The 5 Reasons Why Projects Fail

Do your projects suffer from these undesirable effects?
  • delivery date is well past due date
  • your resources are overloaded
  • your resources are not available when needed (even when promised)
  • your scope suffers from excessive changes (due to long project timelines)
  • there are changing priorities & constant rework

There are five main reasons why your projects struggle with these problems:
  1. Bad multi-tasking - do you or your team constantly face shifting priorities that cause reources to stop one task and work on another? Is someone waiting for the output of your task before they can do their work? This is the definition of bad multitasking.  Often the culprit is poor prioritization. We are asked to start several tasks simultaneously and each of them has a "customer" waiting for the output. Each customer wants progress to be made on their task and constantly asks - "is it done yet?" - forcing us to repeatedly switch to their task to get something done and report progress. While working on this task other customers request status on their respective tasks. This cycle forces us to task switch repeatedly.
  2. Student syndrome - this is also known as procrastination.  Student syndrome is a natural defense mechanism. It means to put off the work until the last possible moment not because we are lazy, in fact we are working very hard, but because urgent tasks will take precedence over important tasks.  Due to competing demands we delay the start of tasks until we absolutely must start.
  3. Parkinson's law - this is defined as "work expands so as to fill the time available for its completion." In a project sense, Parkinson's law rears it's ugly head when team members embed greater safety in task estimates because they feel like their estimates will not be "estimates", but rather committments.  In order to make sure they deliver on their "committments", team members add in slack to allow for the uncertainty.
  4. Task dependency - if you have a task that was estimated to take 5 days and you started immediately, and completed the task “early,” is the person that receives your output ready to use it immediately? Not usually. Therefore, if you deliver the results in 3 days the next person will not touch it for 2 additional days because they are not scheduled to start their task until that time. To overcome this problem you must have a project system that ensures all tasks begin, not when they are scheduled to begin, but when the required inputs are available.
  5. PM math where 2+2=5 - each of the above scenarios contribute to the final reasons why projets struggle..."project math". 
Each of these problems not only drain the company of valuable resources, it also causes a delay in the potential cash flow that results from a finished project.  Remember, if you keep doing what you have always done you will keep getting what you've always got -- late projects. 

To remove these obstacles you will need to stop bad multitasking, develop a system that allows early and late tasks to cancel each other out, account for the probability of dependent events, stop the effects of Parkinson's Law, ensure that when one task completes the results appear almost instantaneously to the next task in line, and stop the practice of adding safety to each task.

Tuesday, April 10, 2012

Interviewing

Project managers and business analysts can spend hours running through SWOT and decision analysis, reviewing system documentation, analyzing various use cases and scenarios, and setting up focus groups and survey questionaires, but ultimately all these techniques may not yield the types of information gleaned from simply interviewing project stakeholders.

An interview is a systematic approach designed to elicit information from a person or group of people in an informal or formal setting by talking to an interviewee, asking relevant questions and documenting the responses.

For the purpose of eliciting requirements, interviews are of two basic types:
  • Structured Interview - where the interviewer has a pre-defined set of questions and is looking for answers
  • Unstructured Interview - where, without any pre-defined questions, the interviewer and the interviewee discuss topics of interest in an open-ended way

Successful interviewing depends on several factors including, but not limited to:
  • Level of understanding of the domain by the interviewer
  • Experience of the interviewer in conducting interviews
  • Skill of the interviewer in documenting the discussions
  • Readiness of interviewee to provide the relevant information
  • Degree of clarity in interviewee’s mind about what the business requires of the target system
  • Rapport of the interviewer with the interviewee
  • Rapport of the interviewer with the interviewee

In relation to other solicitation techniques, the advantages and disadvantages in using interviews are:

1) Advantages:
  • Encourages participation and establishes rapport with the stakeholder
  • Simple, direct technique that can be used in varying situations
  • Allows the interviewer and participant to have full discussions and explanations of the questions and answers.
  • Enables observations of non-verbal behavior
  • The interviewer can ask follow-up and probing questions to confirm their own understanding
  • Allows interviewees to express opinions in private that they may be reluctant to express in public
2) Disadvantages:
  • Interviews are not an ideal means of reaching consensus across a group of stakeholders
  • Requires considerable commitment and involvement of the participants
  • Training is required to conduct effective interviews. In particular, unstructured interviews require special skills including facilitation/virtual facilitation and active listening
  • Depth of follow-on questions may be dependent on the interviewer’s knowledge of the business domain
  • Transcription and analysis of interview data can be complex and expensive
  • Based on the level of clarity provided during the interview, the resulting documentation may be subject to interviewer’s interpretation
  • There is a risk of unintentionally leading the interviewee

Tuesday, April 3, 2012

Decision Analysis

Decision analysis is an approach to decision-making that examines and models the possible consequences of different decisions. Decision analysis assists in making an optimal decision under conditions of uncertainty.

Effective decision analysis requires that the business analyst/project manager understand:
  • The values, goals and objectives that are relevant to the decision problem
  • The nature of the decision that must be made
  • The areas of uncertainty that affect the decision
  • And the consequences of each possible decision

Uncertainty may exist because of:
  • Unknown factors that are relevant to the decision problem
  • There are too many possible interrelated factors to consider
  • Conflicting perspectives on a situation
  • Tradeoffs between the different available options

A common method of dealing with uncertainty in decision problems is to calculate the expected value of outcomes. This involves estimating the percentage chance of each outcome occurring and them multiplying the numeric value associated with that outcome by that percentage.

Decision analysis generally requires that the business analyst/project manager to use some form of mathematical model to assess possible financial outcomes.  Commonly used financial valuation techniques include:
  • Discounted Cash Flow: future value on a specific data
  • Net Present Value: future view of costs and benefits converted to today’s value
  • Internal Rate of Return: the interest rate (or discount) when the net present value is equal to zero
  • Average Rate of Return: estimate of rate of return on an investment
  • Pay Back Period: the amount of time it takes for an investment to pay for itself 
  • Cost-Benefit Analysis: quantification of costs and benefits for a proposed new solution

Not all decision outcomes can be expressed in financial terms. However, effective decision analysis still requires that outcomes be directly comparable. In some cases, there will be a metric that is applicable (defects per thousand, percentage uptime, customer satisfaction rating). When there is not, a relative scoring of possible outcomes will have to be determined.