Estimating big projects. (ERPs)

11 views
Skip to first unread message

Gustavo Cebrian Garcia

unread,
Feb 2, 2012, 9:21:04 AM2/2/12
to scruma...@googlegroups.com
Hello,

I would like to know what is your experience managing the software construction of big ERPs ( Projects of 

You know what is like, a company comes to you and ask you how long this will take, without bearing in mind velocity, or scope changes or anything.

What do you tell the client then? How do you make them think more in an Agile way?

--

Gustavo.

Dan Rawsthorne

unread,
Feb 3, 2012, 4:34:24 PM2/3/12
to scruma...@googlegroups.com
I would ask them how involved they planned to be with the development, and tell them that after I estimate how big the project is I will double the estimate if they won't be involved. This starts the right discussions.

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

Gustavo Cebrian Garcia

unread,
Feb 3, 2012, 9:42:17 PM2/3/12
to scruma...@googlegroups.com
Hello,

Have you used TreeMaps as Mike Cohn does to estimate the projects?

--

Gustavo.

John Clifford

unread,
Feb 6, 2012, 2:00:24 AM2/6/12
to Scrum Alliance - transforming the world of work.
Hello Gustavo,

"How long will this take?" This is an answer that you cannot fairly
answer at the beginning of any sizeable project, at least not
precisely... although given a short amount of time you can answer it
accurately.

The more detailed answer, with specifics, depends upon whether you are
estimating for internal or external customers.

Most external customers want fixed-price estimations with a fixed
delivery date (they want to put all of the risk onto the vendor). In
such a case, unless you have considerable experience with similar
projects through the same customer, you will want to lean towards the
worst-case estimates (as Dan mentioned, go through your internal
estimation process to come up with a reasonable estimate, and then
double the number). Or, you could try to deal with customers in the
spirit of collaboration instead of negotiation; bid based upon
velocity (which you should know for your teams), i.e., how many points
does the company want to buy?

For internal customers, again unless you have historical velocity data
on the team(s) that will be doing the work, you still have a large
amount of uncertainty to deal with. In such a case, you are better off
getting your company to invest a little to learn a lot... something
like buying an option in the stock market. Build your backlog,
estimate it in terms of story points, and then run three sprints. At
that time you should have a good enough trend for velocity to predict
completion dates based upon the project scope. If, based upon that
velocity, you can't get all of the desired scope done by the desired
date, the business folks have some decisions to make about either
cutting scope or giving you more time. The one thing you must push
back on is an attempt to force you to deliver all the scope by the
original time if your velocity data shows that isn't going to happen,
in the hope that somehow it WILL happen. Hope is not a basis for
successful projects.

The key, in both cases, is having the ability to build a suitable
backlog... and that is a subject that is beyond a simple reply on a
forum.

Good luck!

John Clifford
Senior Fellow - Agile Practices
Construx Software, Inc.
'Advancing the Art and Science of Software Engineering Best Practices'
http://www.construx.com


On Feb 2, 9:21 am, Gustavo Cebrian Garcia <g.cebrian.gar...@gmail.com>
wrote:
Reply all
Reply to author
Forward
0 new messages