I’ve been writing again in my blog called tiletrade. I’ve also unlocked it. You can now have access. Most of the writing is about estimating and management, but I also put some posts up about technology since it relates to the process of estimating. If you want to take a look go to tiletrade.

Last Wednesday’s STC meeting got me thinking about my writing style again.  While I’m always writing, it’s not a linear progression from spec to outline to topics to completed project. 

Until I started working in an Agile environment, my progress on a project went something like this:

1. Read the design specifications and functional specifications.  Try to get an idea of what features were being built.  If I was very lucky, the specs would include a use case, describing what the customer wanted the software to do.
2. Count up the number of new applications, tabs, subtabs, actions, dialog boxes, buttons, etc.  This is usually the point when I could start estimating doc effort, as each feature and/or task will usually result in at least one new topic, with a small fudge factor added to cover additional concept or reference topics that might be required.
3. Generate an outline based off the projected UI features.  Each tab or subtab generally gets a concept topic.  Each action, button, or dialog box usually gets at least one task topic, and sometimes two (as in “creating a widget” and “deleting a widget”).  Estimate the number of concept tasks for toolbars, types of widgets, possible widget statuses, commands, etc.
4. Start writing procedures.  Open this, select that, enter something, click save.  If I’ve got a well written spec I can often start on a draft before the software is even coded.  Sometimes you can write a complete draft of procedure before the software is even stable.  But it’s more likely that I’ll end up writing a partial procedure with the first several steps of a draft procedure then write myself a note that “Click X and what happens next? Software crashes as of Build# on Date ##/##/##.” 
5. Next I generally add reference material.  Depending on the software, it might be documenting toolbar buttons, icons, commands, possible statuses, etc.
6. The last thing that I usually write are the concept topics: overviews of new features, descriptions of new tabs, subtabs, screens, best practices.  It usually takes a while to really “grok” the software and how customers will use it.

When we first made the switch to Agile in January 2009, my manager wanted to manage me like the rest of the development team.  The developers had user stories, I had documentation stories.   The developers generated a list of tasks and then estimated story points for their stories.  I generated a list of tasks and topics and attempted to estimate my doc stories.  The developers kept a burn down chart, and I did the same. 

The only problem was, writing documentation is not like writing code and I don’t have a linear writing process.  I don’t tend to start on a topic, write it, and move on to the next topic.  I tend to work on multiple topics at once, writing as much as I can on one topic before moving on to the next.  Sometimes I’ll have an insight in the car during my commute and will need to capture that before I forget it.  I keep notebooks in my car and in my purse so I can scribble notes to myself. 

My manager expected me to work like a developer.  To pick one task and work on it until it was completed.  But I couldn’t write the doc until there was completed code.  And the first four sprints we didn’t have completed code until the last day or two of the sprint.  So if I can’t write until the last couple of days of the sprint, what am I supposed to do for the first three weeks?  (I spent my time closing doc bugs, many of which had been open since before I was hired.)

I wonder how I’m supposed to adjust my writing process to fit into Agile. I’m a multitasker.  I usually work with multiple files open at once.  My brain tends to makes connections between what I’m doing and something that I will be doing in the future, or something that I wrote in the past.  I’m a list maker.  I’m frequently opening up files and making notes of questions, resources, further research to follow up on later.  Part of this is by necessity.  Writers almost never have the luxury of only working on one project at a time.  Especially lone writers.  Right now I’m writing an Installation Guide, working on fixing doc bugs for the next patch release, writing and estimating doc stories for the past several sprints of development.  And my work is dependent on having functional code.  If I try to work through a procedure and the feature isn’t complete yet, I’ll put the procedure aside and work on something else. 

At Wednesday’s STC meeting the two writers said that they document one sprint behind their Agile development teams.  Both of the writers have been doing Agile for three years.  Before we both got laid off, my manager and I had agreed that this was the approach we were going to try.  Now that I’m only working two days a week, I don’t really have a choice but to write the doc after the developers have finished a sprint.

And yet, at the Nashua Scrum Club meeting on Thursday, someone said that if you’re doing testing or writing documentation a sprint behind development that “You’re not doing Agile.”

So, am I doing Agile documentation?  This is a question that I have yet to answer.

Recently I’ve started to think about the concept of time-boxing for user stories.  In Scrum, most things are, can, or should be time-boxed: sprints, releases, planning sessions.  Providing a time  constraint has demonstrated value: it limits the scope of effort, it can curb expensive and unnecessary perfectionist tendencies, it eliminates waste, and it forces prioritization.

One thing that Scrum doesn’t promote is time-boxing of user stories.  We know that user stories are designed to place-holders for future conversations — in other words they aren’t complete and detailed requirements.  We also know that user stories are supposed to be estimated, and that estimates aren’t commitments (well, we should know that). So why does Scrum provide for time restrictions at a higher level, but not at the user story or task level?  I think I answered my own question: the level detail a user story would have to contain wouldn’t support an agile approach to development, and it would mean estimates aren’t estimates but instead are commitments, which we’ve learned is unrealistic in software development.  But I think there’s room to maneuver.

Specifically, in user stories which are complex or involve high technical risk, or in other words user stories that have a good chance of taking way longer than we thought, it can make sense to time box the story, or even the tasks within the story.  I’ve recently asked my team to try this — specifically as a response to ‘technical’ stories which have spun out of control.

Some ideas I’ve floated on how to approach this:

1. Pick a level of effort to commit to on a story; this should be done in consultation with Product Owner (PO) and ScrumMaster (SM).
2. Breakdown the time you need to spend on each task; if this is way beyond the original estimate of the story, have a conversation with the SM and PO.
3. Consider using the Pomodoro Technique to track your time (e.g. if you have given yourself two hours to work on a task, that represents four pomodoro sessions). This will make it easier to not let time get away on you.
4. Just as we prioritize stories in a sprint, prioritize the tasks and acceptance criteria in the story (with either the PO, SM, or architect if it’s a technical story).

Smells:

1. If your acceptance criteria is unclear, this is an indication that a conversation is needed. You should never undertake a story with unclear acceptance criteria — but this is especially true for time-boxed stories.
2. Track your actual effort against tasks and the story and raise the alarm if it looks like the story is out of control.

The final word on this is to use it with caution.  We usually cover around 15 stories in a sprint.  Time-boxing more than one or two is probably an indication that there are bigger problems.

How many of you have estimated a job and wonder how anyone could do it any cheaper and make money?  Well your not alone in your thinking.   There are manufacturers that are using reverse auctions in order to try to get more work and pick up new customers.   The problem is when you have a buyer that is 100% fixated on the price and ignoring the many other many factors presents a difficult problem.

Manufacturing efficiency is one of the areas where you can compete for jobs.   One example I heard of this past week is a large government contract was one by a supplier because of price.   This machine shop could have produced this widget by manually punching the part, but they decided to spend some extra money up front and create a die for the job.  This machine shop had the technical expertise to create the die when two other machine tool makers would not make for them. This machine shop is now able to make these parts very efficiently and one the job because all the other shops that competed with him did not base their quote on a die.

This tells us that manufacturing parts efficiently can overcome many other issues of price during the bidding stage.  Some ways that manufacturing can be more efficient is automatic loaders, robotic welders, automated punch presses, lasers, business software, cad software, estimating software and many other areas.

In this economy I would suggest looking at all your machines and capabilities to try to determine where they can be made more efficient.

MIE Solutions provides software products to make your business process more efficient so please take a look at our product line below.

http://www.mie-solutions.com/mie/

http://www.mie-solutions.com/mie/index.php/MIE-QuoteIt/

After saving time, the next thing that comes to mind is accuracy. Mistakes happen whether you are using a computer or doing things by hand. The computer however, does not make math errors. Consider the chaos of bid day. It is very likely that you will shift a decimal point or make a calculation error in your rush to complete the estimate and get your prices out. Inevitably, prices change, new quotes come in, or the boss wants the labor units changed. I have literally erased right thru a recap sheet because of the number of changes made on bid day. All this rush creates the perfect environment for human errors.

 Assuming you have not started procrastinating after getting a computer estimating system, bid morning comes and there is nothing to do but fine tune the estimate. The computer has done all the math. Changes are instant. Better pricing? New quotes? Changes from the boss? No problem. Now you have time to make some calls. Get  better prices. Find out if alternate fixture packages are out there. Sweet talk the GC’s. In  summary, you have time to concentrate on winning the bid.

 You can still make mistakes entering information into a computer. The saying is “Garbage In, Garbage Out”. Regarding accuracy, the point of using a computer is giving you the time to not be rushed. Remember from Part One of this post, time is saved because the computer explodes the assemblies, creates the listing, prices and labors the material, and does all the math. You are not rushed into making errors on bid day.

 In Part Three, we will discuss organization.

I get asked the question, “What is the average cost of develop software?” all the time.  The answer it depends.

1.  When people ask the average what they are asking is what is the average unit cost of software.  This is a similar question to what is the average cost per square foot of construction.  I use function points, so the question becomes what is the average cost per function point to develop software.    The average dollars per function point is one way to determine the average dollars per unit of software developed.

2. The average cost per unit of software developed depends on several factors.

2a.  The type of business the software supports.  The unit cost of software is going to be different for insurance industry and the aerospace industry.  The same is true with construction.  The average cost per square foot  to build a mission control building for NASA is not going to be the same as the cost per square foot to build an insurance office building.

2b.  Location, Location, Location.  Like real estate the cost per unit of software is going to depend on where it is built.  If the software is built with cheap labor (the main input), then the cost will be less.  Of course it depends if the cheap labor is of equal productivity.  If the cheap labor is half the cost and half as good, then you really do not gain anything from using cheap labor.

2c. Duration.  The duration impacts cost too.  Not only development costs but maintenance costs.  If the the software has to be developed as soon as possible it is going to be expensive per unit.

Actually there are about 50 other factors that impact cost, but these are three big ones.

Read more at Reboot! Rethinking and Restarting Software Development.

Recently, there’s been a story running in the Times about how science students in schools – even A Level students – are being stopped from carrying out practical experiments because of Health and Safety concerns.  Mind you, the Chair of the Health and Safety Executive, Judith Hackitt is quick to deny any part in it.  “The HSE wholeheartedly supports science in the classroom. The thrill of the experiment and learning how to deal with risk is an important part of growing up.” she wrote in a letter to the Editor.

I was fortunate to grow up in the 50s and 60s.  In many ways, this was a gentler age, when, armed with microscope, telescope and a bike, I was able to roam freely, collecting bugs in jam jars and generally being curious.

By the time I started at Grammar School, I had built radio receivers and sound powered telephones and had developed what proved to be a lifelong fascination with science and technology.  The Grammar School was newly opened and endowed with modern, well-equipped labs and dedicated, specialist teachers for all 3 sciences.  Some of my happiest memories of those years are of time spent in a darkened physics lab, firing white painted ball bearings across the room, photographing their trajectory under a strobe light!  From there, my path into engineering (and later into IT) was pretty much guaranteed.

Much later, I tried to instil that same curiosity into my children, taking them to visit power stations, TV studios, even sewage treatment plants (well, do you know how it’s done?).  MrsV1951 and I made sure they had the same range of educational toys and encouraged them to follow a science curriculum at school.  Our efforts included (of course) a chemistry set, and my children (now in their 30s) still talk in hushed tones about the failed experiment to produce hydrogen, which resulted in a loud (but harmless) explosion and coated the windows of the conservatory with a yellowy-brown film.  MrsV1951 failed to understand the significance of our discovery.

My point is this – to excite children about science and technology, you have to let them try for themselves, not just watch a You Tube video.  In the words of the proverb “Tell me and I’ll forget; show me and I may remember; involve me and I’ll understand.”  There’s some dispute as to who originated the saying.  Maybe it was Aristotle, maybe it was Confucius.  In any event, type it into Google and you’ll get more than a million results.  And yet, we seem to have forgotten the central lesson.

It’s a similar story in maths.  If physics is a model of the world we live in, then maths is the language that describes and defines that model.  Going back to my school days, great effort was expended by teachers to ensure that we had the basic mechanics of maths, before we were ever allowed to employ any form of automation.  So, we learned our tables and we learned long multiplication and division and we learned a whole tool bag full of arithmetic techniques that you might collectively call “mental arithmetic”. 

Of course, “automation” in my school days meant log tables or (if you were doing engineering drawing as well) a slide rule.  The first electronic calculators didn’t become readily available until well after I left school.  But again, the same basic argument applies.  My understanding grew from relating theory to what I observed for myself.  For example, I never really understood differential equations, until I needed to apply them to electronic circuit design.

And these skills don’t desert you.  It amuses me that I can work out a calculation in my head faster than (say) a shop assistant can using a calculator.  So, I was fascinated – and highly encouraged – by the efforts of inventor Ilan Samson.  In an effort to encourage people to improve their mental arithmetic, Samson has invented a new type of calculator called QAMA.  He claims that this stands for “Quick Approximate Mental Arithmetic”.  QAMA also just happens to mean “How much?” in Hebrew.

The essence of QAMA is that you enter the calculation you want to perform, but if you then press the Answer key, nothing happens.  You have to enter an estimate of the correct answer, before the calculator will tell you the result.  And now here’s the thing – your estimate has to be close enough to satisfy the calculator.  The tolerance on your estimate varies according to how difficult the calculation is!

Samson is trialling QAMA in schools and early results suggest it can lead to dramatic improvements after just a few days of use.  Try it out for yourself online at http://www.qamacalculator.com/.

So what am I claiming?  In a sincere effort to improve exam results, teachers are teaching children to follow instructions, not to think for themselves.  Calculators can’t replace thinking and video recordings can’t replace hands-on experimental science.  Our ability to continue developing advanced technologies is predicated on our understanding of science and mathematics and these in turn are built upon the basic practical skills learned in childhood.  As Ilan Samson puts it, “If you only carry out tasks that have been performed before, following pre-set rules, you will never be able to solve something new.”

But, I think the last word should go to another source of childhood inspiration, Isaac Asimov …

“The most exciting phrase to hear in science, the one that heralds the most discoveries, is not ‘Eureka!’ but ‘That’s funny…’”

2101455    วิศวกรรมการก่อสร้างและการประมาณต้นทุนการก่อสร้าง    Construction Engineering and Cost Estimating

หลักการวิศวกรรมการก่อสร้าง วัสดุก่อสร้างและวิธีการก่อสร้าง ผลิตภาพงานก่อสร้าง หลักการประมาณต้นทุนก่อสร้าง การประมาณแบบหยาบและละเอียด การถอดแบบ วิธีการวัดปริมาณ การคิดต้นทุนแรงงานและเครื่องจักร

(Principle of construction engineering, construction materials and methods, construction productivity; principle of cost estimating; approximate and detailed estimating; quantity takeoff; methods of measurement, labor and equipment costing.)

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

In job shop estimating where does efficiency play a role?  When you are estimating generally ask yourself how many “Man Hours” are required to producing the part or performing a specific operation.

Lets define some terms first

Man Hours

Man hours is the total time to accomplish a given task.   This does not mean that if a task if 40 man hours it will take five 8 hour days.  You could potentially accomplish the task using more then 1 resource and therefore you can finish the task with 5 people working 8 hours in 1 day.

Direct Hours

Amount of time that an employee is performing a task specific to a work order.

Indirect Hours

Amount of time that an employee is performing a task that is not being applied to a specific work order.  This includes sweeping, cleaning, accounting, etc.

Estimated Hours

Amount of time an estimator puts towards a specific task or job that is an educated guess.

Actual Work Hours

The actual hours an employee spends performing a specific task

Efficiency

Worker productivity is the time spent on a task versus the time they are actually getting paid for.

Worker productivity will never be 100% because of the time interferences a worker keeps from doing their assigned assignments.  These include things like using the restroom, meetings, e-mails, chatting, break time, etc.   The time between direct hours and indirect house is the effectiveness rate.   This is not the the same as efficiency where its calculated as the measure of ones performances performing a given task.

The next blog post will go into more detail and examples of job shop efficiency and effectiveness.

http://www.mie-solutions.com/mie/

http://www.mie-solutions.com/mie/index.php/MIE-QuoteIt/

]]> http://kelleygarcia.wordpress.com/2009/10/15/how-to-avoid-project-estimating-mistakes/ Thu, 15 Oct 2009 13:12:11 +0000 kelleygarcia http://kelleygarcia.wordpress.com/2009/10/15/how-to-avoid-project-estimating-mistakes/

This article captured my attention this morning because it started out with this great quote:

Most every IT project manager knows the sick, sinking sensation of unease when first encountering a project cost estimation error.

I have had that sick, sinking sensation.

But the next paragraph started out with this, and I have a problem with this:

Clients’ habit of either neglecting to mention important details, or simple ignorance of systems’ configurations or previous band-aid strategies, often place project managers squarely in the crosshairs.

Sounds alot like putting the blame on the customers and making PMs the victims to me. Not a good start to a healthy project. I learned very quickly, at the beginning of my PM career, that the best way to be totally accurate with a plan is to start off the engagement with an engagement. Here’s what I mean: Say I receive a RFP (request for proposal) from… where-ever… and it’s three pages of bullets that give me a general idea of what the customer wants. My response to that proposal is going to be maybe as much as three times that length and chock full of assumptions about what they want, information about the processes I’ll use to ferret out the details, and a cost plus a plan to detail out all the actual requirements. Unfortunately customers usually don’t want that. They don’t want to spend three or four weeks being told what they need (they think they know what they need). They are in a hurry, they want to get this project started now, they have the money, the sponsor, the interest, they want to get the ball ROLLING!

The way to make an initial planning engagement appealing to a customer is to promise them deliverables that they can really appreciate. Here are some examples: a full and detailed inventory of what’s being replaced (to use the example in the article referenced above), a flow chart that defines the flow, decision points, and users of the software system, and list of each and every business requirement. In addition to all the work products (deliverables) that you’d provide at the end of the engagement, you’d also provide details about what processes you’ll use so as to completely clarify your project methodology; for example; complete stakeholder identification, change control, risk, and issues management. Last but not least a project plan for the effort that clearly states how much time you’ll need from each member of their team to get the information you need to make even this initial stage successful.

OK so maybe this isn’t appealing to the customer and by the time they’ve finished reading your response they’ve already decided you’re not the delivery team for them. To them this seems like overkill and a horrible waste of time. “But our project isn’t that big, we only want a few things!!” This is one of the most challenging aspects a PM can face because you don’t want to lose the business but you don’t want to shortchange the project and take the risk of the sort of project failure that Mr. Eckel describes in his article as being incredibly common.

But what’s the alternative? Let’s go look at Mr. Eckel’s list of three tips for avoiding project estimating mistakes and see if they’ll be enough for our customer.

1. Confirm all assumptions. I totally agree with this one. Remember I said above that my proposal would be chock full of assumptions – I’d require they all be confirmed before we started the project, as well as everything else in my proposal. Make sure you get a meeting to go through your response. Prepare for it thoroughly. It’s your sales pitch opportunity.

2. Don’t expect trouble-free projects. I have been on the other side of the RFP and received a statement of work proposal that had “buffer” in it. It was called a ROM sizing (rough order of magnitude) and had a +75% / -25% range to it. Think about that. If you have a $1,000,000 project that’s a heck of a range. I don’t think building in buffer is the way to go. I think breaking the project into manageable chunks is a much better solution. And Mr. Eckel even gets there in his last paragraph where he states, “Be sure to build the appropriate time into original project planning documents…” So what if we, as a project manager, talk to our customer about the benefits of agile development processes and how what we’re proposing – a concept plan phase engagement – is just the first step of the overall project but the difference is that at the end of this phase they have a choice. They can take the deliverables and give us the boot. OR they can continue to the next phase with a clear cost and plan for proceeding. It’s a sell job by the PM which is why it’s such a challenge. But as a customer I like the idea of having an opportunity to tell these people to go take a hike if I don’t like what they’re doing.

3. Specify exactly what estimates include. This would map to my list of deliverables. But when I’m in the nitty gritty of a project I have no problems showing my counterpart in the customer’s organization, my detailed work breakdown. I specify ahead of time that it’s not negotiable, it’s there for their information so they are clear on what the effort will be for this job. I also make clear how I’ll report on progress so they will stay clear on the effort and our accuracy. Does it get better than this?

Collaboration and Teamwork would be one of my three tips for avoiding project estimating mistakes. You start by getting people together, being transparent, and sharing the common goal which is the success of the project. Then you work together to lay out all the details in all their glory before you ever code the very first line – even if you’re planning to create a prototype. THAT is the real secret of estimating a project accurately. So my three tips would be:

1. Make your first response to the customer be a clearly documented plan for a plan.
2. Establish a collaborative team of both customer stakeholders and key delivery team members who all agree on the goal(s).
3. Be transparent regarding your deliverables, including your estimates.

This note is mostly a reminder to me to establish context and agree definitions in each of my posts. Project management is a wonderfully rich discipline with such variety that generalizations are challenging. I just dropped out of an extended LinkedIn exchange when I realized that most of the posters there (myself included) were making assertions in the absence of context.

Here’s a simple example … earlier today, I saw a request for “project estimation tools.” The asker made no mention of what type of project or what type of work was being estimated. The tools (and techniques) are quite a bit different if I am:

• Estimating costs for a real estate development project in order to obtain funding.
• Estimating effort for the development phase of a software project.
• Estimating duration for any kind of project.
• Estimating costs for the construction phase of a real estate development project (and here, there are even differences if I am the owner or the prospective contractor).

So next time you talk with anyone about project management … make your context clear.

Cheech and Chong, a 1970’s comic act, portrayed themselves in one of their skits as Siamese twins that were not identical.  They were paternal twins physically connected at the hip.  Of course this was impossible, absurd and a very laughable idea.  Whenever I hear about pair programming I can’t help but think about Cheech and Chong and the absurdity of the idea.    It is like asking two teenagers to share a mobile phone.   It ain’t going to work folks.  It is absurd and laughable.

The idea is that one programmer writes code and the other programmer stands over his or her shoulder and watches for mistakes. When the first programmer gets tired they switch positions.  I think they are suppose to touch hands like professional wrestlers do in a a tag team wrestling match.  How cool would it be to called something like Stone Cold Coder or Diva Developer.  You could go to work dressed in costume.  Instead of programming sessions you could have smack down coding sessions.

You don’t have to implement Agile to try out  the idea of pair programming.  I would suggest  trying pair writing.  Have one person start to type and have another person stand over them and correct them as they go.    This is an awesome idea! I am curious to see how long this process would last.  How about pair cooking?  You have one person cook and another person correct them as they go – nice.  How about pair driving?  You could have one person sit in the backseat and correct the driver.  I think that is called back seat driving.  Sorry pair programming is a joke of an idea and absurd.

——————————————————————————-

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

Reboot! Rethinking and Restarting Software Development.

Agile Methods and Other Fair Tales

If you are having a hard time coming up with a pseudo name for your pair programming team check out the auto Professional Name generator at  wrestles - http://www.wrestlingname.com/

Professional Wrestling -http://www.wwe.com/

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

If we don’t study the past we are doomed to repeat it, any historian (or history buff) will tell you. And yet, when it comes to estimating, if we DO study the past then we are doomed to repeat it.

Of all the potential methods of doing estimation, I thought that building up knowledge about past performances would be one of the most useful for having future estimates which are accurate. Ideally, as enough time passes you begin to see repeating patterns in your projects and can leverage that knowledge to assemble new estimates that are based on the actual prior experiences.

In a journey of trying to continuously improve, what could be worse? Using your historical performances to predict the future is valuable if you are happy with your past performance. The market is never happy with your past performance. Even if that performance is good, your competition will be looking to best you. If you build estimates from your past then you are going to be repeating your past. Parkinson’s law will take care of that for you, even if you try to become more productive.

It may seem like a subtle tweak to using a historical database to create estimates, but I think it is an important one… you can’t just estimate based on past performance. You can use that knowledge, but then you have to be prepared to set a goal for your project that is 10% (or some other percent) better than the last time you did it. You must always be striving for better. Whether you achieve it or not, the culture must be that no matter how good what you have done in the past is, we must always be looking for more. Process improvement is not an event, it is a journey.

In The adoption of Agile I stated that ‘Agile’ is not one method, but a set of common principles and practices. The same goes for ‘Agile Planning’.

I created my My.Fragility framework iteratively over the various software development projects I mastered, all serving to realize a (negotiable) scope within a certain timeframe.

The included Product Backlog Estimation model allows to:

1. Write User Stories. Or Epic Stories
2. Make up estimates in Ideal Time / Story Points
3. Determine Velocity. Possibly, but not advisable, per story
4. Determine #pairs. Consider project elapse time, max = 6
5. Determine #FTE for umbrella tasks. Upon #pairs and complexity
6. Set daily rates
7. Set slack, holiday percentage and coach development
8. Assess result & iterate using other parameters
   
9. Set Value of Stories. Total to be 100 (for relative tracking)
   

The Product Backlog Tracking model implements my Tracking Loops:

This assures a continuous image of spent and expected progress, effort, budget and delivered value, at Product and at Sprint level.

The book User Stories Applied by Mike Cohn was a great source of inspiration. Essentials I still use are:

• User Stories, Epic Stories and micro (tiny) Stories
• The INVEST acronym
• Complexity scaling. I use ‘1-2-5′ (over Fibonacci)

Mike’s publisher (Prentice Hall) has made 2 chapters of his second book Agile Estimating and Planning available, for F R E E:

• Chapter 1: The purpose of planning
• Chapter 3: An agile approach to estimating and planning

Cucumber: Number five will win.
Artichoke: How do you know?
Cucumber: I know it, I promise. He won when I was here last week.
Artichoke: Today’s race was run last week?
Cucumber: Of course not, each race is unique.
Artichoke: What if he does not win today? He may get injured in the
middle of the race or just have a bad day.
Cucumber: Then, I was wrong.
Artichoke: So it’s not a promise that number five wins?
Cucumber: No, it’s a guess. But based on what I know right now it’s
my best guess.
Artichoke: But not a promise?
Cucumber: No, just a guess based on empirical knowledge.

A Cucumber and an Artichoke Meet at the Races

(This an excerpt from the book Pomodoro Technique Illustrated)

I know that many of you have heard this discussion before. However, I have had many requests for this information lately, so here is my take on it.

 The first argument is time. I have often heard when teaching computerized estimating, “I can do it faster by hand”. This may seem true while learning and setting up a system. However, once a system has been learned, you will save about eight hours on a $250,000 estimate.

 You will not save time doing the takeoff (counting and measuring) the plans. Technology has done nothing for these activities, although several companies are working on it. You will save a tremendous amount of time after the takeoff is finished. Here is how it breaks down the paper way.

1. Explode all assemblies and list components on pricing sheets
2. Manually price all of the material
3. Manually labor all of the material
4. Extend the material and labor total for every line on the sheet
5. Total the material and labor columns for every price sheet
6. Have your math double checked by someone else
7. Transfer your totals to the recap sheet
8. Do all the math on the recap sheet
9. Make a quick review, and give it the boss for approval
10. Do all the math over every time a change is made

 When I was a junior estimator BC (before computers), this process took 4 people about 2 hours, or 8 hours total. Then a miracle happened. Jack McCormick came and demoed his electrical estimating system on the Apple II computer. The system performed the above referenced work in about 3 minutes. It only took that long because of how slow printers were at the time. The time savings allowed me more time to be competitive on bid day, and of course allowed me to complete more estimates than before.

 That’s it for part one. The next part will cover, well, I don’t know yet.

The Arizona Society of Professional Estimators and the American Subcontractors Association held a joint meeting in Phoenix entitled, “Building Technology into Estimates: Tech Features That Keep You Competitive”.  James Benham of JBKnowledge did a fabulous job in engaging the audience and touched upon a variety of topics in the estimator’s toolkit, social networking and augmented reality.  He showed applications that should at least be on your radar screen included Google Docs, Google Wave, SketchUp and using a BIM overlay on the job site.  James talked about Facebook Groups being used to manage construction projects,  EOS Advisor for seeing trends overtime and SmartBidNet to simplify Bid Management.  I wonder if those in attendance have gone on-line to research these applications or if they’ve shared this information upstream yet?

What I learned there is while I am always looking at technology, the majority of contracting firms are unaware of the new applications, and gadgets that will shape how we will work and communicate.  They depend on educational opportunities to inform them as most do not have the luxury of a Chief Information Officer. 

The Construction Financial Management Association meeting with Julie Pace of Ballard Spahr LLP has become an annual event.  Making it an interactive presentation, her Q&A was challenging and informative.  Here are a few take-aways you may want to share with your HR department and controller:

• In Arizona, November 1st is the due date for sending unclaimed assets to the state including those unclaimed paychecks
• Every project that has received federal stimulus money will be audited. Be prepared.
• The Department of Labor requires start time & end time on timesheets
• Inappropriate conduct is defined as severe, pervasive and unwelcome.
• You can reprimand a salary exempt employee (like a superintendent) with unpaid time if you dock them one(1) or more full days unpaid time.  No half days allowed.

Of course Julie touched upon FMLA, updated us on card check, what to have in your Employee Handbook or have as a written policy and many other topics like what to look for in a “He Said, She Said” situation.  The most interesting item to me was the NLRB is clear in not allowing employers to prohibit employees from talking about raises.  After all this information, I’ll see you at the water cooler.

When you quote a job and its operations you need to make sure you quote it accurately. Its very important to know that when you quote a job that your rates are high enough to actually turn a profit.

Welcome to the MIE Solutions Job Shop Estimating blog. Fabrication software as in sheet metal software and manufacturing software deals with shop rates extensively for costing. Please comment and continue following as I continue investigating production control and job shop software.

http://www.mie-solutions.com

Pragmatic Bookshelf

Since February, 6000 people have downloaded the draft of my book Pomodoro Technique Illustrated. To have 6000 readers in the first six months was above all reasonable expectations. Many of you have sent me e-mails with comments, corrections and other kinds of feedback. I have read, analyzed, modified, and above all learned an awful lot.

Rumors have spread, and recently it became clear that the book – or a version of it – will be published by Pragmatic Bookshelf. It is as paperback, PDF, mobi (Amazon’s Kindle) and epub (eg Apple’s iPhone and iPod Touch) – perhaps even as podcasts. Right now it looks like it will be released in February 2010.

Thanks to everyone who has helped me so far! I hope you will enjoy the new book.

Pomodoro Technique Illustrated book cover

It feels as though it’s been ages since I’ve written out a good article!  I felt the urge to share, however, when I ran across this article about house painting.  Being that my company does full residential remodeling, painting is one thing that we do in every home.  Every job gets a bit of paint in it, whether it is just a touch up here and there because we’ve moved a cabinet or if it’s the whole house getting painted because we’ve done a full addition.  Either way, I hope that this article comes to be of use to you.  If so, shoot me a message and let me know how it helped!

Enjoy your Labor Day Weekend!!!

-Ginnie

Merrick Design & Build, Inc.

www.remodelwithmerrick.com

House Beautiful (September 2009, p56)

Confessions of a House Painter Q&A

– interviewed by John Montorio

What makes you crazy when estimating a job?

Joe Nicoletti: The assumption that my time doesn’t matter and that I’m ready, willing, and able to offer advice at great length and at no charge.  And when I give the estimate, to be told ‘No, I think I can get it done cheaper.’  A lot of people shop painters not just to compare price, but also to steal ideas that they then will turn around and do themselves, or ask their grandmothers to do for them.  My antenna goes up as soon as I suspect it.  I don’t want to do that dance.

What’s the most common mistake people make when it comes to choosing a painter?

Hiring the cheapest guy, and then expecting too much.  Or hiring the guy you think you can take advantage of, and then having to make all the decisions yourself.

How much prep work should I expect?

It depends on how many moving parts a room has.  Let’s say it has chandeliers, fireplace paraphernalia, alarms, window locks.  We catalog and photograph each item before either removing it or securing it from any damage.  Then when we put everything back in place, it’s an easy check to see if anything was damaged.

Do you believe in brushes, rollers, or sprayers?

You need a combination of all three.  Some of it’s logical, some a judgment call the painter makes.  In most cases, for instance, you wouldn’t use a sprayer on trim.  The key is not only to use fine brushes, fine rollers, and the best airless sprayers, but also to keep them absolutely clean.  Dirty brushes or rollers will leave streaks, and a dirty sprayer will spray unevenly.

Do you paint the trim first, then the walls?

Every situation is unique.  Is there a builder involved?  Other trades-people?  Are the rooms loaded with fine architectural details?  Do the clients have particular preferences?  Some ask you to paint the walls first – they want the instant gratification of fast change.  Others want to gauge the look of the trim work before anything else is done.  Typically, though, it makes most sense to start with the ceilings and the walls, and move on to the molding, door trim, doors, and baseboards.

What are the best paint finishes for different surfaces?

Anything goes these days.  High=gloss oils on walls?  Why not!  Metallics on glass?  Sure!  But if you’re asking what the standard is, I’d say satin or semigloss for doors, moldings, and trim , and flat for walls and ceilings.

Is it worth paying more for the premium brands?

The premiums spread more smoothly and adhere to surfaces better.  They require fewer coats to get that nice uniform appearance.  They tend to last longer.  They’re more resistant to the normal dirt and staining that comes from everyday life, and they generally hold up to repeated cleanings much better.

What’s your feeling about ‘green,’ non-toxic paints?

I think ‘green’ is an overused word, and a little overblown.  A relatively low percentage of clients ask for low-VOC or non-VOC paint.  Frankly, a lot of people consider the level of toxic emissions in paint a negligible risk factor.

How many coats will I need?

A primer is a must.  And generally two or three coats, depending on the condition of the surface.

How long before I’ll need to repaint?

Barring fires or floods or a rambunctious dog, you could go from five years to forever – with normal touch-up maintenance.

What should I do if the painter is midway into a job and I realize the color is all wrong?

Don’t hesitate.  Tell him.  In most cases, he’ll do it over for a minimal charge if the change isn’t too extreme.  If it’s lacquered red and you decide you want white latex flat, that’s going to cost more.

Should I get a written warranty?

Every job should have a signed contract specifying what you’ve agreed to.  It helps avoid misunderstandings, disappointments, and unrealistic expectations.

 How do you manage client’s expectations?

Communicate.  Show them you’re listening.  Be willing to make changes as the job evolves.  Don’t get locked into an adversarial relationship.  You’re on the same team.

What can I do to make life easier for you?

Be open to my suggestions.  Make me feel like a partner, not an employee.  Sure, I want to make money, but I also want to do good work, feel a sense of accomplishment and pride and, yea, even have some fun along the way.  Tell me every once in a while, ‘Hey, that’s really looking good.’  And when the job is done to your liking, say ‘Thanks.’  Makes a world of difference.

Welcome to the MIE Solutions Job Shop Estimating  blog.   Fabrication software as in sheet metal software and manufacturing software deals with shop rates extensively for costing.

There are basically 3 ways to calculate overhead absorption rates which is used to provide your shop sell rate during quoting and estimating.

1. Company Overhead Absorption Rate
2. Percentage Overhead Absorption Rate
3. Work Center Overhead Absorption Rate

Each of these three ways of calculating your overhead absorption has both positive’s and negatives.

Percentage Overhead Absorption Rate

What does an overhead percentage mean?   An example would be a 150% overhead percentage which  means that for every $1.00 of direct labor billed to the customer, the business must collect an additional $1.50 ($1.00 x 150%) for that custom just to cover costs.   There are potentially large variations between total direct labor wage and direct labor cost.    The question is how do we figure the overhead absorption rate.

Definitions

Business Expenses

All expenses found on the company’s income statement (also known as the profit and loss statement).

Overhead Expenses

All costs found on the income statement except for direct labor, direct materials, and costs attributable to outside subcontractors that can be billed directly to a customer’s account. Overhead expenses are absorbed by the business and factored into the selling price as a percentage of the direct labor cost. They include indirect costs such as accounting, advertising, depreciation, indirect labor, insurance, interest, legal fees, rent, repairs, supplies, taxes, telephone, travel, and utilities.

Direct Labor

Labor used to produce products and services purchased by customers. These man-hours are directly attributable to customer activity.

Indirect Labor

Labor used to provide supporting services to the business such as accounting, clerical, custodial, customer services, management, purchasing, sales, and warehousing. These man-hours support business functions that are not directly chargeable to the customer.

Direct Materials

Materials used in the final product or service purchased by customers. These materials are charged directly to the customer’s account.

Overhead Percentage

Ratio between direct labor and overhead expenses. This percentage is used to allocate overhead expenses proportionately to direct labor dollars billed to customers.

How To Calculate Overhead Percentage

Step 1 Determine the “average” hourly wage paid to direct labor employees.

Step 2 Estimate direct labor workdays available in the calendar year.

Step 3 Estimate billable direct labor hours for work year.

Step 4 Estimate billable direct labor dollars for work year.

Step 5 Estimate non-billable direct labor dollars for work year.

Step 6 Estimate all overhead expenses for work year to include non-billable direct labor.

Step 7 Calculate the annual overhead percentage.

A machine shop rate for a job shop manufacturer is not that difficult to compute once you have your income sheet calculations available.   Its important to calculate your shop rate for estimating accurately because if you are off by much you will be losing money continuously.   A sheet metal software package needs to be able to handle calculating overhead rates based on percentage if its applicable to the specific industry.

http://www.mie-solutions.com

The mission of MIE Solutions is to apply advanced technology to improve manufacturing productivity and quality in the field of fabrication. At MIE Solutions, we do not compromise product quality or service. We strive to satisfy our customer’s every reasonable requirement with speed, courtesy and honesty. Our pricing reflects the cost of providing high quality products and excellent service but remains fair. Our goal is to be known throughout the world for the development and production of innovative products. We endeavor to be regarded as the leading supplier of high technology in the sheet metal fabrication. We want our customers to be proud to own MIE products.

]]> http://theartofanalysis.wordpress.com/2009/08/30/agile-qa/ Sun, 30 Aug 2009 19:27:25 +0000 cdpetsche http://theartofanalysis.wordpress.com/2009/08/30/agile-qa/

Here is a copy of an email I received from my project manager regarding Agile development. This is a great answer to a tough question: Is long-term projecting possible using Agile? Well worth the read.

_______________________________________________________________________

From: AgilePM Newsletter [aguanno@agilepm.com]
Sent: Tuesday, August 25, 2009 3:26 PM
Subject: AgilePM Newsletter – Julyl/August 2009 Issue
(Mailing list information, including unsubscription instructions,
is located at the end of this message.)
__
=====================
= AgilePM Newsletter =
=====================
July/August 2009 Issue
Welcome to the July/August 2009 edition of the AgilePM Newsletter. As always, our popular Q&A section is full of questions from readers. If you have an agile-related question that you would like to have answered, please email it to info@mmpubs.com with “AgilePM Newsletter” in the subject line.

AGILE Q&A
————-
Q: We are trying to implement agile within my organization.  The struggle is with senior management who don’t understand that under agile we cannot commit to specific dates or budgets.  What can we do to convince them? (Question by Anonymous in Houston, Texas, USA)
A: Actually, I think there is an underlying misunderstanding on your part that needs to be addressed.  Let’s face facts first:  to manage a business, executives need to know key dates, and due to interdependencies with marketing campaigns, commitments to stock analysts, and tie-ins to other dependent projects, we need to sometimes carve those dates into stone.  Similarly, executives need to manage the cash flow of a business. To do so, they need a pretty accurate forecast for how much cash your project is planning to spend every month.  We cannot (or should not) change these realities – too many other processes rely on this data.  So, where does that leave our project?  Well, if you build a release plan (something many agile teams forget to do) listing all of the planned iterations, along with
the iteration start and end dates, you get a pretty good view of a high-level project schedule.  You can even insert key milestone dates (like the dates your CFO mentioned to the stock analysts) in this plan if required.  Then, if you follow sound agile management practices, the high level plan should rarely change; if it does, it is usually just to add or delete iterations at the end of the release.  Yes, the scope within those iterations may change a lot; however, with consistently-timeboxed iterations, you should not be messing with the overall plan.  You CAN make a firm commitment on dates to the executives, you’ll just vary the scope to accommodate the changes that arise during the project.  Similarly, financial commitments can also be made with some degree of confidence.  To build that initial release plan, you’ll need to know your team size and the expected velocity for that team.  If you know the daily (or hourly) cost rates for the resources on the team, it is a simple matter to multiply that by the number of days in your standard timeboxed iteration.  The result is your burn rate per iteration.  Multiply this by the number of iterations, and you get a good approximation of your final project budget.  The neat thing about using velocity as a forecasting tool, is that as your team’s velocity increases (perhaps due to increased efficiency due to process improvements or increases in skill levels as the team’s experience with the solution grows) the release plan recalibrates to show an earlier delivery date, and ubsequently lower costs (or you could use the savings to incorporate more scope into the final solution).  If the velocity degrades over time, the plan immediately recalibrates to show a later delivery date and higher costs, unless scope is dropped to maintain the original plan.  If your goal is to keep to a firm cost
commitment, then all you do is vary the scope as velocity changes, and you should find that your costs come in very close to what you had forecast.  (Answer by Kevin Aguanno)

This past week was spent collecting proposals for the grouvia.com project, in response to the RFP I sent out last week. I had about a dozen early candidates and two dropped because they didn’t feel they could respond within the very short timeframe I required.

I suppose if I had to do it again (you’d have to put a gun to my head) I’d change my RFP to request that each company put their proposal in a specific format. One of the biggest challenges I found was having to “re-frame” each proposal into a common format so I could put them into kind of a mental comparison matrix. I don’t know if I succeeded that well, and I think when it came down to it I went with my gut feeling about which proposals would ultimately rise to the top of the list. But I believe strongly that gut feelings are generally based in some fact. So after reading each proposal carefully, I had a good sense of what kind of company this was, and whether I felt strongly about them one way or the other.

The three that have made it to the short list are quite different from each other. They each suggested different technologies, they have different approaches, and different personalities. The longest proposal (of the three) is 40 pages long and came with 10 supplemental documents. Another one was seven pages long and I had to go back and ask for some missing information. How am I supposed to interpret that?

BTW I didn’t hold it against any of them for missing information. My turnaround time was very short and they did their best I’m sure. I merely asked for it and they gave it to me.

So here I am with a decision due tomorrow and feeling a little paralyzed by indecisiveness about three major factors:

1. Drupal vs. Symfony (I know, I know, they’re not the same type of thing!)
2. Eastern Europe vs. India
3. Hourly vs. fixed price – there’s more to this but it’s too much to go into here.

Did I mention that none of the US companies I asked to participate responded? The overwhelming majority of the firms are from India. One was from Sweden (they dropped) and one from Ukraine. All their english skills are good, they all offer US based phone numbers, they all work late hours to compensate for the time zone issue. None of the offshore issues are really issues, to me at least. And the prices are all very close, and all within my budgeted range.

So I guess I’ll have to keep you in suspense until next week. If you have any thoughts or commments I’d love to hear them!

* * *