4.4.2: Common Causes of Failure

Loading...

En provenance du cours de University of Alberta

Agile Planning for Software Products

937 notes

University of Alberta

Agile Planning for Software Products

937 notes

Cours 4 sur 6 dans Specialization Software Product Management

This course covers the techniques required to break down and map requirements into plans that will ultimately drive software production. Upon successful completion of this course, you will be able to: - Create effective plans for software development - Map user requirements to developer tasks - Assess and plan for project risks - Apply velocity-driven planning techniques - Generate work estimates for software products

À partir de la leçon

Module 4: Risk Planning

You’ve made it to the last module, congratulations! Here, we’re going to talk about what can cause projects to fail. We’ll start off by discussing common causes of failures, including anti-patterns. Then, you’ll learn how to assess risks, looking at their likelihood and potential impact on the project. We’ll end on an optimistic note by leaving you with strategies for intervening when risks present themselves and avoiding those risks to begin with.

4.4.2: Common Causes of Failure6:07

Rencontrer les enseignants

Kenny Wong
Associate Professor
Computing Science, Faculty of Science

[MUSIC]

In the last lesson I talked about anti-patterns.

In this lesson I'm going to talk about some common causes of project failures

that aren't necessarily patterns.

These are usually referred to as types of project risks.

A risk is something that could potentially cause your project to fail.

You can probably think of a bunch just off the top of your head.

Risks are present in any situation, not just software projects.

In fact, there are risks to doing what you're doing right now.

But don't change what you're doing just yet.

Alternatives come with their own risks.

The first kind of risk I'm going to cover is a scope risk.

This refers to risks that involve expanding requirements.

Expanding requirements is a danger for any project, so

it's how you deal with this risk that affects its impact on your project.

If you have good change control measures,

such as running an agile project, you don't have to worry about it too much.

However, if your project doesn't deal well with change,

you might want to change something.

There are also technology risks.

Technology risks are how likely your technology is to fail.

It's not just about your hardware catching fire in your clients hands.

Technology could mean a certain software protocol that becomes obsolete or

unsupported.

It could mean the technology you're using doesn't scale well with

the clients business.

It could also mean that your team just doesn't understand the technology and

essentially renders it unusable.

Your customers and stakeholders can also pose risks to your project.

Sometimes, customers make promises to provide your team

with materials needed to get going, but they forget or are late in the delivery.

This is a project risk.

Sometimes, clients become apathetic or

your main point of contact changes, another big risk.

Personnel risks are another set of risks.

These could manifest themselves as team members leaving the team.

Especially risky if a departing team member possesses knowledge

that no other team member has.

This could also be manifested in your team not having the talent it needs.

Conflicts between team members.

Or communication issues.

Group think, an anti-pattern I introduced in the last lesson,

is another personnel risk.

There are a bunch of other risks.

Your project could face legal issues, security problems.

Your physical location could be destroyed.

Your management or your development team could lose interest in the project.

Or you could deal with industrial espionage.

Whatever the risk, you need to be able to plan for it.

You're working on a project with one of your developers, Steven.

He tells you that he knows your client, and that they aren't on very good terms.

Steven tells you that his work won't be affected, but

he's not sure if your client would be okay with him working on the project.

Steven isn't sure if the client should know that he's working on the project,

because it might jeopardize the project's success.

Which of the following is the category under which you should

categorize the risk Steven has presented to you?

A. Technology.

B. Client or stakeholder.

C. Personnel.

Or D. Developer?

The correct answer is B.

This issue is a client risk.

Basically, there's a possibility that your project's success

is jeopardized by your client's action.

Since Steven's work won't be affected, this isn't a personnel risk.

Let's hear about some common and

recurring risks that could effect the success of a product.

[MUSIC]

>> Well on early stage, startups in particular,

and with some IT projects, a lot of it is funding.

People grossly underestimate how much effort and skill is required and so

there's often not enough funding.

So when money gets tight, it just affects everything.

People's morale gets lower.

People are worried about their jobs and things like that.

So, it can be a real killer.

So a lot of great ideas and

projects just die on the vine because people didn't cost them properly.

Another thing is personnel.

Particularly, again, early-stage startups or

early projects at a company that haven't been done before.

You sometimes you have to deal with the people you have.

And if you don't have the right type of skill to go from point A to point B,

you can end up with a lot of problems and people start to blame each other.

I thought you could deliver this?

People might have bit off a bit more than they can chew.

So you need to make sure that you're staffing things correctly and

have the right mix of skills and the right roles.

And then another big one that I see everywhere is a lack of planning.

So the agile methods are great for lightweight,

lots of customer interaction, lots of testing, lots of good ideas, but

people get the feeling that we're gonna move really fast and we don't wanna plan.

Well, it's not that you don't plan.

You need to have a plan that's appropriate.

That gives you some flexibility to still be agile congruent.

But most of what I see is a lack of planning.

So, technical teams will think that if they follow a particular process, or

they use particular software solutions, that it'll just work.

Well, it doesn't work.

So a lack of planning is an absolute killer.

100% of the projects that I see fail, they all have poor planning in common.

And the projects that do succeed, they have a plan.

Now the plan may change a lot, but

there's something that comes out of thinking about things, writing it down,

communicating that really helps get people aligned and moving in the right direction.

>> Planning for

risks starts with assessing the magnitude with which they can affect your project.

In the next lesson, I'm going to go over a way in which you can do this.

I'll see you there.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play