SE307 "Software project management" Course5 Defining the project, rest of the steps

Summary

Summary of course 4

Project definition

Investigate costs and benefits Define the project Planning Decide go or no go

Summary course 4

We have seen the first steps how to define a project

Define stage plan and agreement Evaluate business need

Find the best solution

Investigate costs and benefits

Now That you have done the first steps of your project definition and you know that there is a need for it, you can start to estimate the costs and benefits

In a further lecture we will see how to do it in details

What is important is that your benefits should be higher than your costs, otherwise you project will be rejected!

Investigate costs and benefits

Investigate costs

Now we can estimate the cost of the solution

The Finance department may have a list of typical major project cost areas and standard rates for converting people's hours into money:

How much is an IT person How much is a business people How much is your software etc

Investigate costs

This is not an easy thing to do

With the experience it will become easier to know what could be the cost of a project

Investigate costs

If this is an IT project, who is going to estimate the IT development cost?

Clearly it has to be IT. It can take a lot of time and effort for the IT people to get sufficient information about what is proposed even to give a high level estimate.

Investigate costs

Main problem is that many IT people don't know how to estimate their work We will see that in details in a separate lesson But this is one of the most tricky part, because IT people think only in lines of code and forget all the rest:

Test Documentation Error correction .

Investigate benefits

Benefit:

Something that improves

Bring an advantage Bring some profit

Investigate benefits

Is there such a thing as a project benefit that cannot be quantified in financial terms?

No, Every benefit can be quantified.

Investigate benefits

For example if you want to make a project that increase employee's happiness: You can say is that when employees are happy they work more, so they produce more and this save XXX money. You must at least quantify enough of the benefits to justify the project.

Define the project

Now you now that there is a customer need and a benefit for your project. We have decided a solution within the scope, but when we go in details (Business Case) the list of requirement can be very long And if you try to deliver everything that everyone would like in one go you'd be facing a big bang disaster project: this is too big!

Project stages

What is that?

"A two year project will take three years, a three year project will never finish."

What could be the solution:

To split the project in small releases

One big project

It's more visible More focus from senior management because it's big Only one implementation, one disruption to the business Nice clean switch from old to new: No temporary bridges from old to new

Only one tranche of training

One big project

Everything being done only once so lower cost

Plenty of time to do it properly

If it's going wrong, plenty of time to get out before the end But maybe too much time and everything is done at the last minute?

Small releases

Better team motivation

Less spent on project control

Greater flexibility for senior management Learning from experience Easier to handle change Less business risk: evolution not revolution Less waste on never-used functionality Easier to manage four small projects than one large one

Small releases

Easier to commit people for eight months than for three years Fewer people leave during a release project than during the big bang project

Earlier benefits realization

Lower cost overall (yes, it's on both lists)

Define the project

So you decide to break it into releases and you determine what will be included in Release 1. You must tell some very senior people that what they would like won't be in Release 1, it'll be in Release 3 - maybe. This is always a difficult part with a lot of discussions, because if this is not done at the beginning people don't see the

benefit for them and don't want to be part of the project

This is very political!

Define the project

If you don't discuss it and don't be realistic you can have serious problems Remember, I told you about living in reality If your project is not realistic, too big it will fail!

How to decide the releases

In principle include in Release 1 only those things that are absolutely essential on day one, "You want that included? Sure, I'll put it in for you."

Good project managers know how to say "no": politely, firmly, rationally: "no".
Unnecessary things What you absolutely need Rolls royce solution What is priority 2

How to decide the releases

If we break into releases we may have to rethink our costs and benefit to change the scope

You have to do iterations This can take a very long time

Define the project

Now we can continue with our definitions:

decide who should be on the steering committee define and agree roles determine how the project will be managed: issue handling, change control, status reporting... ...

Planning

We have decided what is in Release 1, we need to plan it: High level planning for the all project More detailed planning for your first release We also need to know what must be delivered and then plan who must do what work and when in order to deliver those things.

A key part of the planning of Release1 will be negotiating with the managers of the people we will need

Example of Planning

We will have a separate course to see how to planning in details.

Decide go or no go

You will have to make several meetings to ensure that all the key player (Stakeholder) have the same understanding of the project. You will review:

project's goals and objectives business case summary scope and contents of Release 1 and outlook for future releases planning(s) go no/go points

Decide go or no go

roles and responsibilities who will supply what resources when how status will be reported, how change will be managed, etc risks and how they will be managed

Decide go or no go

Then when everything is clear: The project manager presents to the sponsor evidence: we know what we're doing and we're ready to start doing it.

Then it will be decided if the project can be officially started!

Conclusion

We have seen ho to define a project

Define stage plan and agreement

Evaluate business need Find the best solution

Investigate costs and benefits

Define the project Planning Decide go or no go