Friday, December 7, 2012

Estimation for Project Management and Life in General

As I have read the Project Effort Estimation section of the book called Systems Analysis and Design with UML, 4th Edition from Alan Dennis; Barbara Haley Wixom; David Tegarden, I have learned how managers need to carefully analyze, consider, and even do some calculations to estimate time and effort required to build a system as accurately as possible.


According to the book, project management often requires trade-off decisions along the way, meaning that in order to achieve a certain goal, parting with another or other goodness or goals is necessary. (I personally thought this notion is very similar or the same as 'opportunity cost' in economics term) I thought the book gives the great example for describing what trade-off basically is like:

For example, if a project manager needs to readjust a deadline to an earlier date, then the only solutions are to decrease the functionality of the system or to increase costs by adding more people or having them work overtime.


Estimation is the process of assigning projected values for time and effort. - System Analysis and Design

Assuming trade-offs occurs in a very frequent manner, project managers need to have a basic estimation of how much time, effort, or money is required for the project to be done successfully before the project begins so that they can have an brief image of how the project schedule should look like, and even when they need make critical decisions or 'manage' the project going forward along the way, they can always refer to their estimation.

Of course, as the project goes on and revisions of the project schedules are made, this estimation can be changed as well. Usually, estimation gradually becomes more specific than the one made at the beginning of project development since managers will have more experiences and resources as ingredients of the estimation.

(The book neatly mentions how the process estimation should be made - making use of user cases and user-case diagram through the calculations of important factors such as actors and user cases to eventually create Use-case-point-based estimation, and in addition to those, add some other complexity factors such as TCFs and EFs for estimating time and efforts required for a project. If you are really interested in learning more about those, click the book image on the top-right side, which will direct you to the amazon page of this book.:))

Learning From the Past

The book also mentions how important it is to keep the data and experience somewhat in a visual form so that companies can make use of those, especially when they are in the process of estimation:

One of the greatest strengths of information systems consulting firms is the past experience they offer to a project; they have estimates and methodologies that have been developed and honed over time and applied to hundreds of projects.
Although the key concept that the book teaches is not the process of learning from the past, I thought this is the great practice to apply and make use of, not just in the project management or any business activities, but in our daily lives in general as well.

When I wrote about difficulty of wise planning and its importance, the comment I got from my professor from online class was impressive to me, and I think that was because the process of estimation and planning is very closely related, or depending on the way people think, these are the same thing, but also as I mentioned above, what I learn from reading this book will not only become useful when actually planning or estimating in any project development or anything related to business or work, but the way we behave in our daily lives.

The real challenge is that in a world where you are competing with others you need to get the best estimates possible, and get just the right amount of planning done to achieve your goal. The best approach might be to try and learn from your previous efforts at estimation and try to gradually get better at estimating and working out how much planning to do. - Dr. Joseph


  1. Another beautifully formatted post. I'd be interested to know the source of the images you are including.

    I think you've grasped the main points of this chapter, although one thing I would caution against is the idea that adding more people to a project, or having them work overtime is a reliable way of coping with a deadline coming forward. I think the chapter mentions it as well, but there is a communication overhead as more people are added to a project, which can sometimes be counterproductive.

    Particularly if the project has already started, adding more people can potentially slow things down as much as speed them up, if communication is not managed carefully, OR if the nature of the project is such that it is easily decomposable into sub-parts that different individuals can work on.

    And thanks for quoting my comment in your post - nice touch, although I'd be more impressed if you were quoting other thought leaders from the field of software engineering and systems analysis :-) We're pretty much out of assignments now, but perhaps I should prepare a list of other blogs to be reading, e.g.

    1. Sam, I see, so there are always trade off when making decisions with regard to a project schedule, human resource management for a certain project, etc.. and therefore it is not very easy to say something like "Well, this is always right!!".

      And thanks for introducing me some of the great blog posts! I will definitely check those out! :)

      With regard to my images embedded to my posts, right now I just google the key words by image and just put them.. but I am not sure whether this is right thing to do or not..?