“God is in details”

(Ludwig Mies van der Rohe)

Usually our lab construction projects start with and idea jumping into the head of our customers. They recognize some needs that will justify the growth, and then come to us in order to estimate if it’s feasible, what are the costs and what may be the timeline.

Few years ago, one of our customers, let’s call him Mike _(pseudonym); set a meeting with us, telling us he need new labs to support his R&D efforts. The lab set includes several labs which according to him should be equipped with the same machines as an old lab which we build in the past.

Usually, we send these guys (who know what they want) to our draftsman. They sit together and play with blocks on the AutoCAD. They create a conceptual layout (according to the customer vision) which helps all of us focus on the customer demands (this method is appropriate for customers who know what they want. Sometime they do not know and the layout will be created during the design). Then, we take it and start the estimation work, which the customer need urgently  in order to allocate the required budget.

This time Mike was very hurry.

“We are closing our budget for the next half in few days from now. I do not have time to sit and think of my lab layout. You must give me a rough estimation” he said.

“You know it’s a recipe for disaster” I said. “Counting on estimation without clear demands, except for saying it will be the same as the old lab will be foolish”.

“I do not have a choice” he said. “You need to give a number or we will not have a project at all”. 

Now I was in dilemma. I knew the right thing to do is to insist Mike will give me additional data. But knowing the organization, the cycles of budgets approval and understating the importance of these labs to R&D efforts, I gave up.

I took the final costs of the last similar lab project, did some interpolations, multiply, divide and add the ‘gray hair’ factor.  I got a number which Mike did not like. It seems to him too much. He got freeze when I told him it still +/- % estimation.

Nevertheless he did not have time to argue.  We agreed that Mike will go to his managers and try to get some money to start the design works. Few days pass and Mike return with small budget for design. His managers, he told us, gave him green light.

To make this story short, we hired few designers, did some internal design and conduct our design review sessions. What do you think we got?

I think you understand to where I strived…

The total cost estimation given to us by the designers was 170% than the initial budget. What a mess.

In addition, Mike told us we could forget the +/- % (if we could use it, our problems were smaller). The reasons that cause to this gap:

• Different environments between the current and reference projects.
• Additional demands

I will not describe you the arguments and tension at that time. We solve it together with our customers:

• We did pretty good cost estimation work (comparing the initial one…). We had details on every area; on every task and we map the scope additions. This help our customers recognize what has the major impact on the budget.
• We present them the cost vs. time graph (shown below). With this information they could see exactly when they need to find the funds.

At the end the project was completed. Successfully.

Few things to take:

• Be caution when you use the $/m^2.
• The -/+ % (allow for change, buffer…), especially the + should be taken seriously. During the design process it can be reduced.
• You might not like it, but you will face the needs to do such estimations many times. Most of the time the schedule is so tight that you must supply some numbers fast. Just remember to communicate your assumptions and make sure every one understood them.

Good Luck!

Gilad 

In a previous post, I talked about an idea for sparsifying kernel logistic regression by using random prototypes. I also showed how the prototypes themselves (as well as the kernel parameters) can be updated.

(As a brief aside, I note that an essentially identical approach was used to sparsify Gaussian Process Regression by Snelson and Gharahmani. For GPR they use gradient ascent on the log-likelihood to learn the prototypes and labels, which is akin to learning the prototypes and betas for logistic regression. The set of prototypes and labels generated by their algorithm can be thought of as a pseudo training set.)

I recently (with the help of my super-competent Java developer colleague Hiroko Bretz) implemented the sparse kernel logistic regression algorithm. The learning is done in an online fashion (i.e., using stochastic gradient descent).

It seems to perform reasonably well on large datasets. Below I’ll show its behavior on some pseudo-randomly generated classification problems.

All the pictures below are for logistic regression with the Gaussian RBF kernel. All data sets have 1000 examples from three classes which are mixtures of Gaussians in 2D (shown in red, blue and green). The left panel is the training data and the right panel are the predictions on the same data set by the learned logistic regression classifier. The prototypes are shown as black squares.

Example 1 (using 3 prototypes)

After first iteration

After second iteration

After about 10 iterations

Although the classifier changes considerably from iteration to iteration, the prototypes do not seem to change much.

Example 2 (five prototypes)

After first iteration

After 5 iterations

Example 3 (five prototypes)

After first iteration

The right most panel shows the first two “transformed features”, i.e., the kernel values of the examples to the first two prototypes.

After second iteration

Implementation details and discusssion

The algorithm runs through the whole data set to update the betas (fixing everything else), then runs over the whole data set again to update the  prototypes (fixing the betas and the kernel params), and then another time for the kernel parameter. These three update steps are repeated until convergence.

As an indication of the speed, it takes about 10 minutes until convergence with 50 prototypes, on a data set with a quarter million examples and about 7000 binary features (about 20 non-zero features/example).

I had to make some approximations to make the algorithm fast — the prototypes had to be updated lazily (i.e., only the feature indices that have the feature ON are updated), and the RBF kernel is computed using the distance only along the subspace of the ON features.

The kernel parameter updating worked best when the RBF kernel was re-parametrized as .

The learning rate for betas was annealed, but those of the prototypes and the kernel parameter was fixed at a constant value.

Finally, and importantly, I did not play much with the initial choice of the prototypes. I just picked a random subset from the training data. I think more clever ways of initialization will likely lead to much better classifiers. Even a simple approach like K-means will probably be very effective.

Ehsan Ardestanizadeh posed a little problem in Young-Han Kim’s group meeting before break and Paolo Minero presented a cute solution which I thought might be of interest. It’s related to ideas my advisor, Michael Gastpar worked on in his thesis.

Suppose I have a Gaussian variable that is , so zero-mean and unit variance. If I observe where is also and independent of , the minimum mean-square error (MMSE) estimate of given is just

and the MSE is . The question is this: can we somehow get an MSE of less than 1/2 by “encoding” ? Suppose now we can take any function and let , and but with the restriction that . That is, the encoding cannot take any more power.

The answer is no, and comes via an “information theoretic” argument. Consider the vector version of the problem where you have iid unit variance Gaussians and you want to estimate from where is iid unit variance Gaussian as well. The goal is to minimize the average per-letter distortion:

This is just the problem of joint source-channel coding of a Gaussian source over an AWGN channel with quadratic distortion and encoding function must satisfy a unit power constraint. For this problem the rate distortion function is

and the capacity of the channel is . Since separate source coding (compression) followed by channel coding (error control) is optimal, in order to get distortion the rate so . Furthermore, this is achievable with no coding at all by just setting .

Now if there was a scheme for the single-letter case which got MSE less than 1/2, we could concatenate it to get a vector scheme with distortion less than 1/2. But since in the optimal code, we get a contradiction. Thus encoding does not help in the single-letter case either. If isn’t Gaussian the whole story changes though.

Geometry is useful for more than just passing the sixth grade.

In October, I posted on estimation as an essential analytical tool to have today (and more importantly, tomorrow). It’s useful for scheduling, planning, purchasing, and other decision-making circumstances. Well here’s a quick and easy geometric technique for estimating the height of very large things. All you need is an intermediate height of reference (perhaps a friend) and your eyes.

For this example, I will use a friend as my intermediate point of reference and a large building as the object for which I wish to estimate the height.

Line up your friend between you and the building. Your friend should be positioned so that when your eyes (A) are as close as possible to the ground, the top of your friend’s head (C) lines up with the top of the building (E). You’re essentially creating the hypotenuse of a large triangle!

Now, let’s label and identify the other parts of our picture.

Here are our labels.

Given this picture, geometry tells us that certain relationships exist.

Therefore, three easy estimations must be made in order to get the estimated height of the building (y):

       w = the distance between you and your friend
       x = the distance between you and the building
       z =  the height of your friend 

NOTE: Be sure to use the same units in your estimations (feet or yards, perhaps) or else your calculation will not work. 

Once you have those three values, just leave the rest to geometry. You have basically created one right triangle inside another right triangle, assuming the building and your friend are both standing up straight. Therefore they have equal angles and therefore equal ratios of their legs, allowing us to make this simple calculation. The result:

Math is fun, right?

I regularly meet with our departments’ PMs (I tried to do it every week) to discuss their project progress. The meetings official target is to discuss the risks in their projects and how they are going to mitigate them, but usually the meetings deal with a lot of other things.

 Couple years ago, after we got our semiannual budget, I had a meeting with one of the PMs. His project scope was to upgrade part of our conference rooms. As it was look like very simple project, the project manager did not actually understand what I want from him with all this risks, processes and meetings.

This was a short period after I started my new role and before we implemented new projects selection processes for our semiannual budget requests, which include ranking projects according to our current objectives and various templates – include cost estimation template.  

 In order to keep the anonymity, let’s call him John. The conversation looks like that (I summarize it):

Me: “Hi John. How is your project going, something special?”

John: “No, nothing special.”

Me (trying to create a discussion):” Good. Did you open a project in our PMIS? Do you have all your quotations? Did you meet with the EHS guy and with the electrical guy?”

John:”Electrical guy? Why? I am just going to replace the carpet, paint the walls and replace the acoustic ceiling”

Me:”So, if you touch the ceiling, what about the lights dismantling and installing again? Did you ask the electrical team if they want also to replace the light to T5 model (same standards as in our new rooms)? Did you check with the IT department what impact it has on their equipment in each room and with the person responsible for cleaning about the impact on the other spaces?”

I started to see John face becoming gloomy. When we continue to talk, I again got to the conclusion that nothing in project management is simple. What look like a very simple project, got into budget problems due to wrong cost estimation process.

We estimate our costs before we start our projects. It can be done with a team of architects and engineers in large and complicated projects after part of the design was completed and can also be done by the PM in very simple projects.

The only thing we should keep in our mind, no matter who does it, is to work according to some processes and templates which will make sure we do not miss something. Like John.

Actually, the fundamental problem of John was that he did not involve all the relevant people in his project (actually he did everything by himself). This would have prevented him doing these mistakes. Nevertheless, if he used a proper cost estimation template for summarize his costs; he might recognize it in advance.  

Our current cost estimation tables include all the relevant disciplines a construction retrofit project includes (Electrical, civil, HVAC and so on), automatically adding to it the indirect and AFC parts. This reminds the project manager about other packages which he might miss. Also when reviewing the project during the projects selection process, we review his cost estimation and challenge him about disciplines he did not request any budget for.

Some useful advices for doing cost estimations:

• Work according to the project WBS. If you can, create a basic WBS template for your projects.
• Be carefull from $/Area estimations. It can help you verify other estimation made in other methods but not by itself.
• Do not work on your estimation alone. Even if it look like simple project.
• If you can, get estimation from some contractors.
• Keep in mind when estimating to separate the capital budget and the expense budget.
• Do not forget to include the AFC (allow for change) and indirect costs.
• Estimation method can change during the project. $/Area estimation might be enough in the project initiation (with the AFC adjusted according to it). You need to use more precise methods during advance stages.

I did not describe how the specific package can be estimate:  parametric, according to historic data and so. This will be cover in future posts.

Good luck!

Gilad

202431     เศรษฐศาสตร์และการประเมินราคาทางวิศวกรรมเคมี     Chemical Engineering Economics and Cost Estimation

การอ่านข้อมูลทางการบัญชีและงบการเงินของอุตสาหกรรมเคมี การประมาณราคาต้นทุนของเครื่องจักรอุปกรณ์ในกระบวนการผลิตทางเคมีและการวิเคราะห์เชิงเศรษฐศาสตร์เพื่อประกอบการตัดสินใจในการออกแบบโรงงานทางวิศวกรรมเคมี การวิเคราะห์เชิงเศรษฐศาสตร์ในการเลือกกระบวนการเคมี และการลงทุนในอุตสาหกรรมเคมี

(Interpreting the accounting data and financial statements in chemical industry, chemical process equipment cost estimation and economic evaluation in chemical engineering plant design, economic evaluation for selection of alternative chemical processes and investment in chemical industry.)

(202431 มหาวิทยาลัยเกษตรศาสตร์)

203462     สัญญาข้อกํ าหนดและการประมาณการก่อสร้าง     Contract, Specification and Construction Estimation

การประมาณราคาการก่อสร้างรวมถึงด้านการเงิน งาน ระยะเวลา และวัสดุ เพื่อสามารถนํ ามาวิเคราะห์ข้อมูลทรัพยากรที่มีความจํ าเป็นสํ าหรับวิธีการหาเส้นทางวิกฤติ การเขียนรายละเอียดและข้อกํ าหนดสํ าหรับแนบในแผนงาน การทํ าสัญญาเพื่อการก่อสร้างและขั้นตอนการดํ าเนินการตามสัญญา

(Construction cost estimation involving budget, work, time limit and material to be used in resource analysis required for critical path method; details and specification listing for attachment with the plan; construction contracting and work procedure under the contract.)

(203462 มหาวิทยาลัยเกษตรศาสตร์)

240453     การสํารวจปริมาณและประมาณราคา     Quantity Survey and Cost Estimation

หลักการและระบบการประมาณราคา การคิดคํ านวณวัสดุ แรงงาน อุปกรณ์และค่าใช้จ่ายในการก่อสร้าง ตลอดจนการคิดภาษี กํ าไร และคิดค่าใช้จ่ายอื่น ๆ

(Estimation by UNIFORMAT and CSI method calculation of material and labor. Quantities separated by building system. Computer application in cost estimation.)

(240453 มหาวิทยาลัยเกษตรศาสตร์)

241451     การประมาณราคาในงานภูมิสถาปัตยกรรม     Landscape Architectural Cost Estimation

หลักและวิธีการประมาณราคางานทางภูมิสถาปัตยกรรมในขั้นเตรียมโครงการ ขั้นออกแบบ และขั้นก่อสร้าง การคํ านวณวัสดุ แรงงาน อุปกรณ์ การคิดภาษี กํ าไร ค่าใช้จ่ายในการก่อสร้างและค่าใช้จ่ายอื่นๆ

(Principles and methods of cost estimation for landscape architectural projects in the process of preparation, design and construction. Calculation of material, labor, equipment, tax, profit, construction and miscellaneous expense.)

(241451 มหาวิทยาลัยเกษตรศาสตร์)

Our development team recently went through a transition period that involved the introduction of a couple of team members.  We aggressively track velocity week to week.  These numbers not only help in planning releases, but also to gauge the health of the team and process.  I generally disregard the first few sprints (sprint = 1 week) for the team to get comfortable with each other and the tools.

I should note here that the team is using a fibonacci scale of estimates and generally has features between 1 and 5 points.  This project is also made up of significant legacy code and is being “stabilized”.  Bugs come in regularly and don’t get estimated.  Big changes to the application need to take in to account existing users and their similarly legacy data. (Legacy here means old and originally developed with minimal QA and tight time constraints)

The first 5 sprints for this team were quite encouraging.  After a 3 week bootstrapping period there was a strong sense that the team was building up to a strong pace.  The team had a rough sprint 6, but they seemed to bounce back the following week.  Sprint 8 had another collapse.  By this point we were looking at 4 weeks and only completing 20 points.  What is going on?  Sprint 4 had us expecting twice that pace.

I’m very fortunate to have a reliable team, a very skilled and experienced team lead, and a patient set of stakeholders.  As we began seeing the fluctuating velocities for what they were (a problem with our process) all of us began looking for causes and solutions.  I’ve seen this before.  The team got about 6 weeks in to the project, everyone was beginning to feel confident that we were doing things right, and then we started to lose control.  We’d nail one sprint only to completely miss on the next one.  It was frustrating and demoralizing.

We got through it.

The root cause came down to unanticipated externalities.  That means that a task would get held up because we needed an icon from the designers, or we needed content for the new email, or our acceptance criteria were vague enough that developers couldn’t quite tell if they were done until QA approved or rejected the work.  The team wasn’t quite sure if their work was done and tasks would get rejected at the end of every sprint for often minor issues.

What did we do to fix it?

The biggest change was to add detail to the acceptance criteria and make sure our QA process would verify exactly to the acceptance criteria.  This ultimately was my fault and by getting QA to strictly focus on the ACs it put pressure on me to get as much in to the ACs as I could, otherwise I’d need to create a new user story to tune it and that may mess up my timelines.  I like to call this approach “strategic pressure points”.  The goal is to strategically put positive and negative pressure and side effects to encourage those best practices that we all say we should follow but often lose motivation after a few times.

The other shift in think came more as a side effect of the first.  That was to hold on to user stories until I had all of the content and graphics ready to go with it.  In an ideal world we’d be able to drop a designer directly on the team and turn the graphics problem from an external issue to an internal one.  This gives the team (plus one designer) control over their ability to complete the stories that they accept in to a sprint.

The key to this turnaround is a return to the basics.  What do the numbers say?  What is going wrong or right; what is causing frustration in the team members?  And, what can you do to make things incrementally better?  Keeping our eyes on the metrics that we are collecting helped us track the instability of our process and allowed us to focus on specifics when looking for problems.  Constantly looking for things that aren’t working perfectly and finding ways to make them slightly more perfect helped us respond to the problems rationally and see rapid recovery from the issues that were affecting us.

Estimation Considered Wasteful

Estimation, to predict some attribute of the future, is a common method tool. Estimation has long been a standard, some would say overused, tool in the tool box of most development teams. However, these last years estimation has been called out for questioning.

Estimation has always been problematic. One problem is that estimates are often perceived as promises, which they are not. They are only forecasts. Another issue is that estimates, just as weather forecasts, are often wrong. Putting too much weight on an estimate spells trouble. The majority of the criticism, though, does not focus on these problems, but instead on the inherent wastefulness of the practice.

I was recently part of an interesting session, arranged by Johannes Brodwall and Lasse Koskela, at the ØreDev 2009 conference, where we performed a “shoot-out” between some common, agile estimation techniques. The ensuing discussion got my brain started and at the end of the session I blurted out a suggestion for the “Rules of Estimation”, which everyone seemed to like. These were also inspired by Michael Jackson’s wonderful “Rules of Optimization“. So here they are, in a slightly enhanced form. First the rules, then the explanations.

Rules of Estimation

1. Organise the work to make estimation superfluous.
2. (If avoidance is not possible) Do estimation quickly, relatively, iteratively, in collaboration, and with as little precision as allowed.
3. (For experts only) Do estimation in a blink, using gut feeling.

Or in shorter form:

1. Avoid it
2. Do it (if you must)
3. Feel it (for experts only)

Explanations

1. Organise the work to make estimation superfluous

There are pretty clear indications that estimation often is wasteful. By wasteful, I mean it does not add value to the customer. No customer ever ordered an estimate. Some people may regard it as “necessary waste”, work we need to do to perform the really important work, but Toyota and Lean has shown us that this is actually a fallacy. We are capable of organising our work to make estimation unnecessary.

To be clear, I am not talking about breaking down large tasks to smaller tasks to understand them. Also, I am not talking about discussing the need or ROI of a certain feature, nor designing a possible solution to these needs. I am simply talking about the act of estimating for the purpose of guessing how “big” something is.

If you think about it, the only objective of estimation is to give a basis for some kind of promise. For example, we may estimate a project to be able to offer our service at a fixed price (a promise). Hence, if you are able to organise your work in a way that promises are not needed, you may save yourself the time and the energy of estimation work.

Examples of techniques that help eliminate the need for estimation are supply chaining, i.e. close collaboration with suppliers thereby removing the need for scoping contracts with attached deadlines, active maintenance, i.e. the marriage of business and IT in a continuous business development activity, thereby removing the notion that one part is a customer and the other a supplier even though both work for the same company, and Kanban, part of which involves working without iterations, thereby eliminating the need for committing (promising) during iteration planning.

There are certainly occasions were some estimation is beneficial, for example to coordinate a large marketing campaign with a major product release, but these cases are outliers and may be handled in a much more agile way than is standard practice today.

To work without the need for estimation is the route that should be preferred and we must insistently strive to get there.

2. If avoidance is not possible, do estimation quickly, relatively, iteratively, in collaboration, and with as little precision as allowed

For some situations, and for most teams today, avoiding estimation is simply not feasible. Some developers are caught by sales people to make off-the-cuff project estimates for their next tender. Most developers estimate projects, even if done in-house. Even agile teams estimate, for release and iteration cycles. While you are working on the cultural change of removing unnecessary work you have to estimate.

If you must estimate, then I suggest you do the work with these principles in mind:

• Quickly, using simple tools. It is pretty obvious that we should at least keep wasteful work to a minimum.
• Relatively. Estimate the size of each item in relation to other items. Then, derive the length in time as soon as we know the duration of a few items, as suggested by Mike Cohn. This is a self-correcting, ego-free system.
• Iteratively. Estimate several times, with additional information and justification of estimates between rounds. This page lists some scientific research that support collaborative, iterative estimation.
• In collaboration. The best estimates are made by more than one person, preferably a team coming from different perspectives (cross-functional).
• Imprecisely. Use as little precision as you are allowed. It is more important that the estimate is correct rather than precise. “In the future” is a better answer than “Oct 2″ if you really have no clue when you’ll be done. Use a range and a unit that communicates the level of uncertainty you experience.

3. (For experts only:) Do estimation in a blink, using gut feeling

As I am sure the reader can tell, the second route is a lot of work. It is also a difficult and treacherous path that may lead you horribly astray. Anyone who has been in a fixed-price project that is overdue knows what madness that may surface in these stressful circumstances. But there is actually one pretty powerful short-cut: Use experienced experts.

If you can get a number of experts in the same room, estimating in collaboration using the techniques mentioned above, the estimation may be done quite quickly. These expert can tell in a blink, using questions and gut-feeling, if this is going to be a three-week, three-month or a three-year project. How this works is really a little bit outside of what we know, but “intuition” or “pattern matching” can be quite trustworthy in these cases, see “Blink”, by Malcolm Gladwell.

The first caveat to this is that they would have to be true experts. They must be seasoned veterans (at least 10 years of experience in the field) that have performed similar work in the past.

Another issue is that they may not be willing to do it, often for good reasons. If you have questioned their estimates in the past, or passed on the consequences of a missed forecast to them, they will certainly be suspicious of your intentions.

Conclusion

To conclude, I believe we are better off viewing estimation as a wasteful practice. Since it is wasteful, we should strive to organise our work to make estimation unnecessary. If that is not possible at this time, perform estimation as quickly, simply, and cleverly as possible. Always remember that estimation is a forecast, not a promise. Communicate that uncertainty in the estimates. Using true experts is a powerful way to make good enough estimates in an efficient manner.


How many people are having sex at this instant? How many piano tuners are in the city of Chicago? How can we come up with reasonable estimates to questions like these?  On this program, Dr. Aaron Santos discussed how to estimate anything.

Where’s the owl when you need him…

LISTEN TO EPISODE

« La rareté et les chefs d’œuvre » est le titre d’une de mes émissions coréennes préférées. Dans les épisodes typiques de l’émission, des propriétaires d’objets d’antiquité espèrent évaluer le prix de trois d’entre eux. Ces antiquités sont analysées par un groupe de quatre commissaires priseurs, chacun d’entre eux étant spécialiste dans la céramique, la peinture, les meubles ou la calligraphie. Pour chaque objet, on raconte son histoire, la façon dont il a été trouvé et ce qu’il signifie pour son propriétaire. Cette émission est pour les spectateurs une invitation à un voyage vers le passé.

La dernière fois, une personne âgée a présenté un pot à épices en porcelaine qui s’était transmis de génération en génération dans sa famille. Je n’oublierai jamais ce monsieur à l’air très fier, un peu tendu et qui parlait avec verve. La date de naissance de cette petite merveille se situait au 16^ème siècle, elle était utilisée par le peuple, pas par les aristocrates. Sa simplicité et sa sobriété m’ont charmée dès son apparition à l’écran.

Comme toujours, au moment où le prix devait être révélé, j’ai serré les mains sur mon cœur et retenu mon souffle. Le son du panneau électronique qui désigne le prix me donnait de légères vibrations dans tout le corps. Et voilà son prix ! “Quoi ? Ce n’est pas vrai !” Je n’en revenais pas, je n’en croyais pas mes yeux ni mes oreilles.

Le visage du propriétaire exprimait mille sentiments sans aucune parole. Hélas, ce pot ancien n’était nullement apprécié à sa juste valeur. De façon insensée, on accordait à cette porcelaine de 500 ans une valeur à mon avis trop basse. A vrai dire, cet événement est fréquent. Car même les antiquités ne peuvent se libérer de la loi de l’offre et de la demande d’aujourd’hui.

Ni les 500 années passées à garder en vie cette matière fragile, ni l’esprit persévérant et dévoué de l’artisan qui apparait dans le processus de fabrication n’ont été pris en considération. Et la porcelaine de l’arrière, arrière, arrière….grand-mère a quitté l’écran avec son propriétaire dépité… Je suis restée assise un certain temps à ma place, avec un goût amer dans la bouche…

 Hyojin SEONG, étudiante coréenne, 5° année design

It’s very easy to influence people’s answers based on the questions you ask. For example, if you ask a leading question such as… So you’ll have that report on South America finished by Friday, right? Then you’ll be much more likely to get a positive (and possibly misleading) response than if you ask something more balanced along the lines of… When will the report on South America be complete? Of course, there’s a big difference between getting the superficial answer you want and getting the true, underlying data you need to make an accurate estimate or decision.

The questions you ask determine whether you will get realistic information back or not. Be careful how you phrase them. Balanced questioning can be critical in spotting potential problems early.

If you want to take it to the next level, you could probe after the initial question. When’s the earliest you’d could ever produce the report, what would cause that to happen? When’s the latest you’d get the report, what would cause that to happen? That way you can move from a single point estimate to a range of outcomes, with the latter being more reflective of the real world.

Detecting reliably an event is surely something to worry about in applied science. One of the main models used is the perfect-imperfect detector, obviously underlying a Poisson process…  Two detectors are counting events generated by a source (eg a photon device). The first one detects efficiently (perfect) the events whether the other one lacks efficiency.

Then X~Poi(λ) and Y~Poi(λp), where p is the inefficiency ratio and estimation is (almost) trivial. Assume that m,r are the counts of X,Y respectively. Furthermore, let k be the total observations and n the observations of X.

The mle of λ is m/n as usual. What about p?

The likelihood is proportional to , so taking logarithms and differentiating with respect to p gives us that the mle is .

The real question is : what if ?

Look it up… S. S. Chitgopekar, “A note on the estimation of the Poisson parameter,” International Journal of Mathematics and Mathematical Sciences, vol. 8, no. 1, pp. 193-196, 1985. [pdf]

2102534    ทฤษฎีการประมาณและการประยุกต์    Estimation Theory And Applications

แนวคิดเกี่ยวกับทฤษฎีการประมาณ และเกณฑ์การประมาณในการสร้างแบบจำลอง ตัวประมาณเชิงเส้น กรรมวิธีสโตคาสติก ตัวประมาณเชิงเส้นที่ไม่เปลี่ยนแปลงตามเวลา การประมาณไม่เชิงเส้น การประมาณให้คล้ายที่สุด การประมาณโดยวิธีกำลังสองต่ำสุด การไอเด็นติไฟระบบ

(Estimation theory concepts and criteria; modeling of stochastic processes; linear estimators; time invarian linear estimators; non-linear estimation; maximum likelihood and least square estimation; system indentification.)

(2102534 จุฬาลงกรณ์มหาวิทยาลัย)

2101453    การประมาณและวิเคราะห์ราคา    Construction Cost Estimation and Analysis

หลักการประมาณราคา วิธีการก่อสร้างและเครื่องมือที่ใช้งาน การหาปริมาณวัสดุจากแบบและรายการ การวิเคราะห์ต้นทุนของแรงงานและเครื่องจักร

(Principle of cost estimation; gross estimation; detailed estimation; successive estimation; quantity take off; cost analysis of labour and equipment; principle of cost control.)

(2101453 จุฬาลงกรณ์มหาวิทยาลัย)

In order to communicate progress to someone who requires a quantitative number attached to it, some sort of consistent metric of accomplishment is needed. The table below lists some of the commonly used size metrics in the software development world.

All of these metrics suffer to some extent from a “consistency” problem. The problem (as exemplified in the figure below)  is that,  unlike a standard metric such as the “meter”, the size and meaning of each unit is different from unit to unit within an application, and across applications. Out of all the metrics in the list, the definition of what comprises a “Function Point“  unit seems to be the most rigorous, but it still suffers from a second, “translation” problem. The translation problem manifests when an analyst attempts to convert messy and ambiguous verbal/written user needs  into neat and tidy requirement metrics using one of the units in the list.

Nevertheless, numerically-trained MBA and PMI certified managers and their higher up executive bosses still obsessively cling to progress reports based on these illusory metrics. These STSJs (Status Takers and Schedule Jockeys) love to waste corpo time passing around status reports built on quicksand like the “percent done” example below.

The problems with using graphs like this to “direct” a project are legion. First, it is assumed that the TNFP is known with high accuracy at t=0 and, more erroneously, that its value stays constant throughout the duration. A second problem with this “best practice” is that lots, if not all, non-trivial software development projects do not progress linearly with the passage of time. The green trace in the graph is an example of a non-linearly progressing project.

Since most managers are sequential, mechanistic, left-brain-trained thinkers, they falsely conclude that all projects progress linearly. These bozelteens also operate under the meta-assumption that no initial assumptions are violated during project execution (regardless of what items they initially deposited in their “risk register” at t=0). They mistakenly arrive at conclusions like: ” if it took you two weeks to get to 50% done, you will be expected to be done in two more weeks”. Bummer.

Even after trashing the “percent complete” earned-value-management method in the previous paragraphs, I think there is a chance to acquire a long term benefit by tracking progress this way. The benefit can accrue IF AND ONLY IF the method is not taken too seriously and it’s not used to impose undue stress upon the software creators and builders who are trying their best to balance time-cost and quality. Performing the “percent complete” method over a bunch of projects and averaging the results can yield decent, but never 100% accurate, metrics that can be used to more effectively estimate future project performance. What do you think?

Americans like to think of themselves as friendly. Yet others find us impersonal and rushed. We come on too strong too fast; we are intimidating to some foreigners. We then fail to fulfill the implicitly promised friendship; we seem phony. In most parts of the world, friendships are slow to form, requiring tremendous commitment and attention over the long term. Anything less than the gradual and deliberate approach may be seen as insincerity, and insincerity compared to the seriousness with which friendships are taken elsewhere. Once formed, many foreign friendships are virtually permanent. And with the friendship come obligations, not only to help in emergencies, but to help in a number of ways the average American would consider entirely unreasonable.

The importance of relationships strongly affects the conduct of business. The foreigner needs to assess any business associate and most likely will make a deal not purely on the basis of the best price or product but rather on personal estimation. From Italy to China, extra personal involvement is important; many foreigners feel that if both parties can be friends, then business between them will flow naturally and smoothly.

My Consultancy–Asif J. Mir - Management Consultant–transforms organizations where people have the freedom to be creative, a place that brings out the best in everybody–an open, fair place where people have a sense that what they do matters. For details please visit www.asifjmir.com, Lectures, Line of Sight

The ability to accurately estimate a target value is an asset to any brain. Learn to hone this ability, embrace it, and use it to optimize your life.

Our lives are surrounded by invisible data – most of it in units of time, energy, space, and money. Essentially, our brains are huge folded databases that store this data, and use it to make decisions, plan ahead, and live each day. But as with many types of data, there exists some uncertainty about that data. Unknowns about how long, how big, how much, from where, until when, should i, almost enough, maybe tomorrow… well you get the picture. Our life data is filled with unknowns.

That’s why estimation is essential. Without it we’d get lost, fall behind, and lose our sense of security and awareness. Whether we know it or not, our brains constantly work to estimate and approximate values, given set of life data at that moment in time. And whether we know it or not, our brains run predictive models to assess hypothetical scenarios, basically using present life data to predict future life outcomes.

These are important realizations, and strong connections of human nature to an innate mathematical realm. Estimation is both an art and a science, as it takes creativity and thought supported by various numerical methods. Having the mathematical ability to estimate proves useful in most situations, but without the artistic component, you lose the ability to understand and contextualize your estimation.

The main point here is that estimation should be embraced as part of human nature, supported by numerical methods. This is how we can optimize our life – by recognizing the units with which our lives are measured each day, and reducing as much uncertainty in those values as humanly possible. It will not make you completely successful and happy and secure, but it will get you close.

Examples

Here are some random examples of estimation from my life. The methods of estimation vary, but the fundamental questions being asked all have outcomes of an unknown nature.

1. Shopping: Budgeting $150 for a dinner party, break budget down to categories of purchases then allocate funds accordingly. Estimate totals and percent of total budget category to make decisions on necessity.
Outcome: Go bigger on the dinner and ask a couple guests to bring desserts.

2. Sports: Ten minutes left in the game, down by 2 goals. Have two full lines of players so will sub soon and again with 4 min left. Need at least 1 goal every 4 minutes leaving a 2 min buffer to protect the tie and go for a win, should allocate 60% of strategy to offense and 40% to defense for next 8 minutes. If I’m in for 6 min and need 60% offensive mindset, how inclined should I be to make a run towards the goal, leaving my defensive position?
Outcome: Win

3. Personal Finance: How much to take out at the ATM? Need to estimate expenses for the week – lunch, happy hour, gas, dinner, cab to meeting, etc. How often will I use my credit card? Am I more inclined to spend if I have cash? Will I be near another ATM this week if I need more cash? How conservative should I be in my spending given the holiday season is arriving?
Outcome: Take out $60 and bring lunch.

4. Daily Planning: Got a hour-long meeting at 3:30pm, soccer game at 6:30pm. Assuming there will be traffic, it will take me 35 minutes to get home then 5 minutes to change, 10 to heat up leftovers, 10 to eat, and 15 to switch and fold laundry. Need 25 minutes to get to field and 15 min to warm up. Will I have enough time if my 3:30pm meeting goes long or do I need to put off the laundry and/or dinner?
Outcome: Always put off laundry, but never dinner

Links

Estimating how much gold there is in the entire world
Estimating how much money there is in the entire world
Estimating the height of anything using geometry
A bit about estimation in statistics

The GenEstim function presented here uses a very simple genetic algorithm to estimate parameters. The function returns the best estimated set of parameters ($estim), the AIC ($information) at each generation, and the cost of the best model ($bestcost) at each generation.

Results of running the program with a logistic function :

Logis = function(x,p)	p[[1]]/(1+p[[2]]*exp(-p[[3]]*x))
RSS = function(par)	sum((Logis(X,par)-Y)^2)
aic <- function(yvalues,rss,par)
{
	k <- length(par)
	n <- length(yvalues)
	aic <- 2*k+n*log(rss/n)
	return(aic)
}
P	<-	list(2,10,4)
X	<-	seq(from=-5,to=5,by=0.1)
Y	<-	Logis(X,P) + rnorm(length(X),sd=0.1)
plot(X,Y,pch=19,col='grey')
GenEstim	<- function(
		start.pars,
		cost = RSS,
		...,
		numiter = 1e3,
		npop = 1e2)
{
	bestcost <- NULL
	cur.AIC <- NULL
	for(it in 1:numiter)
	{
		pop <- matrix(0,ncol=length(start.pars),nrow=npop)
		for(p in 1:length(start.pars))
		{
			pop[,p] 	<- rnorm(npop,start.pars[[p]],sd=1)
			pop[1,p]	<- start.pars[[p]]
		}
		Costs <- NULL
		for(i in 1:nrow(pop))
		{
			li <- as.list(pop[i,])
			Costs[i] <- cost(li)
		}
		bestcost <- c(bestcost,min(Costs))
		best <-which.min(Costs)
		start.pars <- as.list(pop[best,])
		cur.AIC <- c(cur.AIC,aic(Y,RSS(start.pars),start.pars))
	}
	return(list(estim=start.pars,information=cur.AIC,convergence=bestcost))
}

simul <- GenEstim(list(0,0,0))
x.control <- seq(from=-6,to=6,by=0.1)
lines(x.control,Logis(x.control,simul$estim),col='orange',lwd=3)