Whether you’re a C-level executive, an entrepreneur or a project manager, you may not have encountered very many troubled projects in your career, so you may not be familiar with how to transition from chaos, to crisis, and finally to calm. We consultants are often brought in to deal with just such problems, so I have a few tips that should help:

1. Don’t Panic! Douglas Adams references aside, you may have just learned that a key project is in trouble, but it’s important that you not panic. First of all, panic spreads, so you create chaos from crisis, and it won’t be long before your co-workers and your subordinates are panicked, too.Second, panicked people don’t reason effectively – they make “fight-or-flight” decisions instead of rational ones, so you’re far more likely to make a bad decision or push others to do so.
2. Be Methodical. At Cedar Point Consulting, we have a 5-step process that we follow to recover projects – Review, Recommend, Respond, Transition, Close. While this is not the only way to recover a project, it does consistently work – by step three, the project is making progress once again. Regardless of the technique or methodology that you choose, don’t attempt to solve the project’s problems until you have an understanding of their causes. Do take measures to stop the bleeding, until you’ve effectively identified root causes.
3. Read the Tea Leaves. Whether well run or not, nearly all projects have documents that tell you where the weaknesses are and whether they are being managed well. At minimum, even the smallest project should follow a standardized process ( project methodology); a charter (with a project goal); a project plan that includes a schedule, a budget, and assigned staff; regular meeting minutes and regular status reports. If these exist, review them to assess where problems are occurring. If they don’t, find out why.
4. Be From Missouri (“Show Me”). Reading current project documents is a good start, but what if someone is fudging the numbers or painting a rosier picture than reality? For select documents, like staff hours, project schedule and project budget, confirm that they are reasonably accurate independently. Which brings us to the next tip…
5. Use an Independent Third Party. Whether you hire a consultant or have someone in another part of your business lead your project recovery effort, they should be an independent third party. Having a friend of the Project Manager, the Project Manager’s immediate superior or one of their subordinates jump in to help is unlikely to be successful.
6. Change Leadership or Change Process. At the most basic level, projects most often fail because either the project manager is not up to the task or the project management process is preventing them from succeeding. A good project manager controls time, scope, cost and quality on a project. If they don’t control at least two of these and influence all four, then they are likely to fail. Conversely, if they control all of these but the projects headed off a cliff, you probably need to switch project leadership.
7. Increase Communication. When you’re trying to identify problems with a project, it helps to increase communication within the team. Schedule and require participation in regular meetings – daily, if necessary, like Stand-ups or Daily Scrums. Finally, increase the frequency of status reports to key parties, such as the client, the sponsor and key stakeholders, even if the reporting is informal.
8. To Thine Own Self be True. There’s always a need for optimism in every situation, but good leaders are also honest to themselves and to others about the current state of a project. Depending upon how far behind the project truly is, consider reducing scope or resetting the schedule. Failing to do so may doom the project and the project team to yet another failure – one from which they may not recover.
9. Start Small, Review Frequently.  After you’ve planned your recovery, be sure to start with small deliverables and shorter milestones, reviewing the project’s progress frequently to make sure the conservative short term goals are being met. While this is not normally the best approach with a project, starting small enables the team members to practice working together as a team before they have to tackle the larger, more challenging deliverables of the project.

The list above isn’t a comprehensive recipe for solving all the problems of a troubled project or for complete recovery, but it is a good start.  In a subsequent post, I’ll provide a list of ways to minimize the possibility of troubled projects altogether.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy.  Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

One would think the same truism would apply to running a business, particularly when building a business from the ground up. As many entrepreneurs and small business owners know, it’s not uncommon to work 60 or more hours a week when starting a business; customers and clients will come calling at all hours of the day and night; and, sometimes you have to stretch more value out of a few bucks than a third-world soup kitchen. Even when the business is stable, vacations are never truly vacations – there’s nearly always a crisis that requires your input, which prevents even three-day weekends from being work-free.

So it may surprise some of my friends and business associates that, after running a business for a little over five years in the first decade of the 21^st century, followed by roughly five years working for others, I’ve decided to start another business again in 2010. There are a few reasons I’ve decided to do this, but here are the most significant:

• Running a business enables me to pursue my passions. As with any consulting business, your client is your first priority. However, after all of the client’s work is done, there is still time to improve your own business, to research new innovations in your industry, and to help your co-workers to learn and grow, too. Along the way, if you identify a new market or business opportunity, it’s yours to pursue – no approvals necessary.
• Running a business enables me to consult in multiple areas, preventing me from being typecast as solely a “strategist”, a “technology expert” or a “project management guru”. If you are both a voracious reader and an experienced practitioner, it’s amazing how effective you can be in many disciplines, not to mention the synergistic benefits of being knowledgeable in many areas. As an entrepreneur, you aren’t bound by the practice area or job title that someone else gave you – you are bound by the knowledge and experience that you truly hold.
• Running a business enables me to live according to my own values. A number of years ago, a former PR Manager for an energy company told me why he’d moved out of PR and in to HR by saying, “There was an incident at one of our plants where an employee of our company had made a mistake. I was head of Public Relations, so I wanted to say to the public, ‘We screwed up, we’re sorry, but here’s what we’re doing to make sure it won’t happen again.’ Instead, I was told to deny that the incident ever took place, which was a flat out lie. I did what was asked, but I couldn’t bear the thought of the next time an incident occurred and I’d have to cover for our mistake.”
  While few events in business pose moral challenges as great as what he faced, there are day-to-day decisions that may help your business but harm your soul. As a business owner and a Christian, I can say how nice it is to be able to do the right thing should the need arise, yet not have to worry about whether I’ll land in the unemployment line.
• Running a business adds weight to my advice. It’s one thing to say something because you’ve seen it work for others, and an entirely different thing to speak from firsthand experience. As a consultant, so much advice is based on observation, but as a business owner, you not only speak your advice you live it and breathe it. Your clients know this, so they respect your advice even more.
• Running a business enables me to balance work, family and charity. There are many myths about running a small business versus working for someone else that I’ve uncovered during the past ten years, but the most important factor is this: Never was I more able to meet my clients needs, to arrange my schedule around family activities, and to put in time to perform charitable work than when I ran my own business.

I can safely say that I have met many wonderful people while working for other businesses, I have served a number of clients that were well worth the time and effort expended, and I have worked with some very talented leadership along the way. In addition, I have served more than a few Fortune 500 companies and managed more than a few multi-million dollar endeavors in the process.

However, I’m looking forward to living the life of a small business owner once again. I know it’s considered by many to be one of the hardest jobs to hold. But it’s also a very fulfilling life, one that holds the most promise for me to positively impact others – and it’s nothing, apparently, like owning a boat.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in strategy, process improvement and project management.  Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

What should you do next?  “Celebrate,” I say, “then chalk it up as a win.”

What? Not the answer you were expecting?  Let me explain…

I spend quite a bit of time in a classroom, whether its to teach a subject or to learn myself.  During one class, the oft-cited Standish Group statistic that measures projects successes reared its ugly head once again, this time citing a roughly 30% project success rate with roughly 45% qualifying as challenged (Standish Group 2009).  Per Standish, roughly 70% of projects fail to meet expectations – a sobering statistic.

A project manager sitting behind me who specialized in pharmaceuticals shocked me when she said, “Gee, I wish our numbers were that good [in our industry].  The odds of a clinical trial resulting in the drug reaching market is 1 in 20, and this is after its cleared a number of internal hurdles to justify a stage I/II trial.”  (A stage I/II trial is early in the process and serves as a pilot).  While I laughed at her comment, I also considered how it related to the Standish statistics and definitions of project success.

By her definition, success meant bringing her product all the way to market, an unlikely outcome by her own estimation and by those of my fellow health sciences colleagues.  But, what if success was defined as, “Accurately determining whether a product should be brought to market,” or “Successfully determining whether a project should continue past the pilot stage”?  Suddenly, many of her projects would be considered successes.  After all, how many drugs don’t work, have ugly side effects, or have the potential to kill their patients?  Isn’t she and her team successful if they keep bad drugs off the market and aren’t we better off for it?

In the software industry, good software methodologies use pilots, proof-of-concepts or prototypes to determine whether a software product is worth fully developing and fully budgeting.  In the Rational Unified Process, the rough equivalent of a pilot is called the Lifecycle Architecture Milestone and its purpose is to confirm that the greatest technical and design hurdles can be overcome before additional funding is provided to the project.  In Rapid Application Development prototyping is embedded in each and every iteration (cycle), while paper prototyping is a part of Agile development.  Regardless of the methodology, these steps are designed to provide results early, but they are also designed to confirm that a project is worth completing, providing an opportunity to change course or shut down the effort when it’s not.

So, maybe it’s time for those of us in the PMO and portfolio management to change they way we measure project success.  Right along side the “projects successfully completed on time/on budget” statistic, there should be two others — “projects successfully killed because their pilots proved they simple weren’t viable,” and “dollars saved by ending unfeasible projects early.”  Because in the end, a pilot’s failure is just as good as a pilot’s success, as long as you listen to its message.

I recalled a day in economics class over decade before, when I learned about the Cobb-Douglas function (http://en.wikipedia.org/wiki/Cobb%E2%80%93Douglas), which states that productivity is a function of capital equipment, labor and technology. In short, Cobb-Douglas says that an increased investment in technology or capital equipment (machinery, tools) increases the productivity of your employees (laborers). This seemed obvious, so I tucked it away in my mind as a good example of conventional wisdom transformed in to a simple equation.

During my years consulting, I’ve seen Cobb-Douglas at work numerous times – at a large computer manufacturer where my team deployed over $1 million in computer hardware for collaboration for their 250,000 employees; at a global heavy manufacturer who built out identical server farms for their plants; at a top-10 financial institution where a dot-0 software upgrade (version 2.0, version 3.0, etc.) triggered the purchase of entirely new corresponding hardware. In most cases, we prepared business cases that showed (1) there were sizable productivity gains through the purchase and (2) the cost of replacing hardware during a corresponding software upgrade was far lower than waiting a year or two when the hardware was seeing high failure rates and affecting customers or workers.

I’ve also seen Cobb-Douglas ignored by otherwise-successful entrepreneurs. While this may seem surprising to some, if you understand the mindset of the entrepreneur, then you’ll understand why. You’ll also understand why this is not good policy for a thriving small business.

For many entrepreneurs, the key to initial success lies in boot-strapping – finding creative ways to deliver for customers despite the lack of resources necessary to get the job done. In most cases, small business owners build their business from the ground up by repeatedly stretching human resources to make up for the lack of capital investment or technology, rewarding these employees with equity or large delivery bonuses in exchange for working lots of overtime. As time passes, the entrepreneur equates scarcity and heavy workloads with success, and a pattern that ignores Cobb-Douglas is engrained.

All is well until the business grows, resource scarcity is no longer necessary and the rewards for burning the midnight oil are no longer available. The business has entered its teen years and is in need of some major infrastructure investments, but the entrepreneurial leader has trouble making the investment. Too many years of boot-strapping have made it difficult to imagine making a sizable, long term investment in technology or productive equipment. It’s safer, the thinking goes, to keep doing what made you successful – boot-strapping.

Yet the business has changed and the keys to past success are not the keys to future success. Businesses may start by successfully bootstrapping, but they grow by improving product quality, normalizing operations and building brand, all of which require substantial investment in technology, people and resources. Few entrepreneur’s recognize this shift occurring, so their business suffers “growing pains” until leadership transitions to someone else.  Dr. Rudy Lamone, a now-retired professor of Entrepreneurial Studies and former dean of the University of Maryland RH Smith School of Business, echoed the observation that entrepreneurs are often replaced once they’ve grown a business past a dozen employees, primarily because the behaviors that led to past successes are now detrimental to the business.

As a result, it’s not uncommon to encounter a small thriving business that uses ten-year-old computer hardware and six-year-old desktops for seemingly inexplicable reasons.  The cobbler’s children have no shoes, but not for lack of leather and nails.

What has been the impact?

1. One entrepreneur lost their largest client by failing to buy and implement a defect tracking system capable of handling a dozen developers and QA resources. The software was delivered, but it was so defect-ridden that the client’s employees could hardly use it.
2. Another entrepreneur lost two key developers who grew tired of developing on old desktops and outdated software.  When the phone call came from a recruiter to work for a business that provided new equipment and regular training, they jumped ship, creating a one month backlog of development work in their wake.
3. A third entrepreneur suffered a one week outage of their production system because they failed to stock a redundant firewall for their network.  The pricey firewall, a $5000 unit, had a one week lead time for replacement.  The cost was $80,000 in revenue and breach-of-contract complaints from nearly every client.
4. A fourth entrepreneur, mentioned at the beginning of this blog, suffered a three-day outage, but was able to avoid a breach of service level agreements by holding the network together for two more months, then upgrading the infrastructure after the contract was renewed.

The effects of tacking care of the cobbler’s children are evident to me, but they’re still anecdotal.  So, I’m asking small business owners and entrepreneurs – when your business is thriving, do you hesitate to make long-term investments in infrastructure? If so, why? If not, what criteria do you use to make the buying decision?

Confirming All’s Well

Because leadership changes usually occur when change is needed, it may be difficult to tell that nothing is wrong. But there are a number of indicators that appear when everything is just fine. If you answer “yes” to most of these questions, you’ve probably inherited a steady ship:

1. Your predecessor retired. While some people are forced in to retirement and not all recent retirees were good leaders, it’s a good sign that all was managed well if your predecessor retired in the position.
2. Your predecessor held the position for more than 10 years. Particularly in disciplines like information technology and marketing, ten years is a mark of seasoned leadership. While times may have changed and forced a change in leadership, it’s a good sign that your predecessor enjoyed the position enough to stay in it for a decade or more.
3. Turnover was low. You’ve talked to the staff below the prior leader and they average five years or more with the company. This means the prior leader knew how to hire and retain the right people for their positions.
4. The numbers are good. Whether the key performance measures for the division are customer satisfaction, profit-per-unit-sold or days-ahead-of-schedule, the key measures all look good, especially after some independent validation confirms they’re accurate.
5. You’re allowed to phone your predecessor. When both sides haven’t parted on good terms, it’s rare that you’re allowed to pick up the phone and call your predecessor. When you ask, “Do you mind if I give the prior manager a call?” an answer of “yes” with no cautions or caveats is a good sign.
6. The echo of kind words. In initial conversations about your predecessor and their work, co-workers and subordinates speak fondly of them and readily point to past successes.

If you’ve responded, “yes” to 4 of 6 of the indicators above or more, there’s a very good chance you’re inheriting a well run division or team that needs few short-term changes. The next section describes how to lead in this situation.

An Even Keel

Once you’ve confirmed that all is well, you have quite a management challenge ahead of you. (Yes, that’s correct – a challenge). Your predecessor was well liked, the team performed well, and you have to do at least as well for the transition to be considered successful. Here’s what you should and should not do:

1. Give credit. Once you’ve confirmed prior success, give credit to your predecessor and the team, noting that you respect what they’ve already accomplished. This is more than phony ego-stroking, it’s confirmation for your staff that you knew can properly assess a business situation and take the correct actions moving forward. They’ll appreciate that you’re recognizing them, but they’ll respect your business intuition even more.
2. Avoid radical change. While it’s very tempting, do not try to transform the organization to suit your own management style and don’t attempt a major reorganization. It’s likely to cause resentment by your co-workers and subordinates who were very happy with the way things were. Even worse, it may turn a productive team into an unproductive one.
3. Make change slowly. An obvious converse of the prior point, if some changes are necessary, make them slowly. This will give people an opportunity to know and trust you, but it will also give you time to understand why the team was so successful in the past. After a little wait, you may find that some of the changes you’ve planned aren’t needed and it will definitely put the distance of time between you and your predecessor.
4. Learn from the management style of your predecessor. They were successful sitting in the same chair you now hold – who better to study than them? Review old reports and deliverables, review performance results going a few years back, and see how the division ran in the past.
5. Give them a call. Invite your predecessor to lunch and ask them what worked so well. What management style did they use, what methodologies or techniques. Also, if possible, ask them about your staff – what are their likes and dislikes, what makes team members tick, who doesn’t get along with whom? In a couple of hours, you’ll be a lot closer to making a smooth transition.
6. Review goals, then consider more ambitious ones. It’s possible your predecessor already set some pretty solid target for the team, but there’s also a very good chance that the bar has been a little too low most recently. If this is the case, raise expectations a bit, work with the team to identify new opportunities to excel, then add them to your strategic plan. By doing so, you’re most likely to add value to an already good situation.
7. Adjust. While it may not be YOUR management style, your predecessor’s approach worked well. Consider adopting all or part of it, even if it’s a stretch for you. You may find that you grow as a leader by adding arrows to your quiver in this way.

Same Crew, More Knots

As a manager and leader, taking on a successful team may be the most challenging experience you ever face. It’s likely you’re a leader because you can take charge in difficult times to steer a new course, but the winds of change simply aren’t blowing. In this case, the most prudent course is to learn from the successes of the past and adapt to the new team. It will take longer, but eventually your team will improve upon past successes. If nothing else, resist the temptation to immediately set a new course – ironically, you’re far more likely to fail.

“You should be quite successful,” I told my father, “if you’re able to deliver products that are of such high quality to the automotive industry. Who wouldn’t buy a product that meets specifications so precisely?”

“That’s actually the problem,” my father responded. “We can build parts to one ten-thousandth of an inch, but the automotive market doesn’t need anything that precise and isn’t willing to pay for it. It costs an awful lot of money to build something that precise and to verify that it meets that standard.” He continued, “It will take us a while to figure out how to mass-produce products with much lower tolerances that are also competitively priced.”

Many years later, I encountered the same issue in my own career. Educated like many others in the principles of total quality management (TQM) and the concept of “zero defects”, I believed that the key to building excellent software was a clean defect log.  Budgeting time for multiple rounds and types of testing, my team and I dutifully worked to test 100% of all functionality in our systems and didn’t release our software until every known defect was repaired.

The day came to release our software and I was met with an unexpected surprise. Sure enough, not many defects were reported back, but there were defects reported. Why?

It turned out that our large user base was exposing problems that neither our QA team nor our beta testers encountered or anticipated. Only through the rigors of production use did these defects come to the surface. This was my first lesson about the limitations of preaching a “zero-defect” mantra – nothing replaces the “test” of production.

During our project retrospective, an even more important downside to the blind pursuit of “zero defects” surfaced. Over the two extra months our team spent addressing low-severity defects, our client lost roughly $400,000 in new sales because the new system was not available to collect them. (I had done the ROI calculations at the beginning of the project showing a $200K per month of new income, but had completely forgotten that holding on to the system for a couple of months meant the client would be deprived of this money entirely-they were not merely delayed). For the sake of perfection, zero-defects meant withholding key benefits – this was a far more important lesson than the first.

Certainly, few users want to deal with defects in software, particularly software that’s not ready to deliver. And, of course there are software products where a near-zero defect rate is extremely important. For example, I’d be quite upset if a zero-defect standard weren’t set for the key functionality in an air traffic control system or in certain military, aerospace, medical and financial systems.

But now, before I recommend a zero-defect quality target for any project, I make certain that the costs of such a high level of quality are not only beneficial to the client, I make certain I include in my calculations the lost benefits the product will bring to the users by holding it back until this level of quality is achieved. After all, none of us like defects, but would we really want to wait the months or years it might take before we reap the benefits from a new version of our favorite software?

As a former developer, my knee-jerk response when asked, “How much time…” was almost always to respond with the correct answer – but under only the best possible conditions and outcomes.  It was only when I began managing projects that I saw how often my estimates were low and began to understand why.  I’ve coined this under-estimation of work effort on an individual task or unit of work “Developer’s Optimism”, though it’s just as likely that any other member of a project team could make this mistake.  Developer’s Optimism has many causes,  but it can be alleviated using a few basic cures, or adjustments, to the estimating process.  I’ll explore both the causes and the cures in today’s blog.

The Cause

Developer’s optimism is, on the surface, what the phrase states – a well-meaning software developer or other expert on the project team gives an estimate that is theoretically possible but highly unlikely.  In most cases, the developer may be quite experienced, yet their estimate only has a one in ten chance of being accurate.  Why?

It’s not that the developer wants to ruin your estimate, though you may begin to believe this is the case if you’ve had this occur with the same person repeatedly.  In nearly every case, he or she has made one of six mistakes in their estimating that you need to help them avoid, as described below:

1. He did not include unit testing.  In most cases, a developer will not include unit testing in their estimating, particularly if you phrased the question as we did in the first paragraph.  In most developer’s minds, the work is done when the last line of code has been written on an alpha version, not when testing has been completed.  This common difference in dividing lines can throw off your estimate by 10-25% or more.
2. She did not include re-work.  Perhaps all of your developers do perfect work and they deliver the first version of their code working exactly as your specifications are written. But, then the client takes a look at the outcome during a prototyping session and says she’d like a few changes.  Depending upon your client’s level of scrutiny and detail, this could bias your estimate downward by between 5-50%.  Sure, change requests can add hours to cover this, but isn’t better to plan for a moderate amount of change in advance, rather than come back and asking for more time and money mid-project?
3. He estimated based on his own skills and not those of others.  Hoping for a better estimate, project managers nearly always go to only senior developers, designers and architects to benefit from their experience – big mistake!  A senior developer will almost always tell you how long it will take them to do the work themselves, not how long it will take the average developer.   Inevitably, when the time comes for the project manager to staff their team, the senior developer is not available and the estimate is unrealistic.  In this scenario, it could take as little as 10% and as much as 10 times longer (yes, doubting senior manager reading this now – 10 times!) for an inexperienced developer to complete the same work as an experienced one – particularly if the senior developer is not available to provide coaching or guidance.
4. She estimated her portion of the work but did not include the work of others.  In this case, she’s spot-on with her estimate, but she’s the user interface (UI) developer and not the database developer.  So, if you use her estimate, the hours are gone and the UI looks beautiful, but the database queries/procedures aren’t written and the graphics haven’t been spruced up by the graphic artist.
5. He did not include bug-fixing.  Depending upon how you estimate testing and quality assurance, you may or may not assume that the developer has included time to make bug-fixes in their estimates.  In most cases, he has not done this, because bug-fixing often occurs weeks or months after the code was written.  Depending upon the complexity of the task and experience of the developer, bug-fixing typically takes between 10% and 30% more time than completing the work itself.
6. She did not account for complexity and risk.  In some cases, project managers never ask the critical follow-up question to “How long will this take?” — “How hard is this?”  When asked, we begin to understand how complex and risky the task actually is.  Particularly if a project involves many high risk tasks, one of these tasks is certain to face many setbacks as it is developed, blowing our initial estimate out of the water.  For high risk tasks, it’s not uncommon for the task to have a 25% chance of taking twice as long.

The Cure

Fortunately, project managers can cure their teams (and themselves) of Developer’s Optimism by taking roughly a half-dozen steps when making their estimates.  These include:

1. Asking multiple individuals to estimate.  Instead of asking one senior developer, ask two or three developers of varying skills, then average their work.
2. Use analogous estimating.  Analogous estimating uses historic project data to look back at the level of effort spent to complete similar tasks in prior projects. It then adjusts them based upon the differences between old and new to estimate time for the current task.  As a result, analogous estimating takes away some of the risk of downward bias that is so common when project estimates are developed.
3. Make it clear what “this” is.  When asking the question, “How much time will THIS take?” make it very clear what THIS entails – are you assuming THIS includes unit testing, bug-fixing, re-work, the work of other team members, or none of the above.  If none of the above, be certain to include these in your own, separate estimate.
4. Add “…an average developer…” to the question.  Instead of placing the developer in the position of assuming they will do the work, ask them to assume that they WON’T do the work by rephrasing, “How much time will this take for the average developer?”  In many cases, the developer can remember their skills when they just started or when they were a few years on the job, and will give you a better estimate.
5. Assess complexity and risk.  For each task and the project as a whole, conduct a risk assessment and set aside a legitimate number of hours for risk contingency based on the probability of a specific approach to completing a task failing and the likely number of hours to develop an alternative if the primary fails.  Risk management is a key discipline in project management – one that impacts your estimation as much as it does your execution of the project.
6. Use PERT.  Not a shampoo, many project managers have encountered Program Evaluation and Review Technique as a way to estimate project duration and level of effort.  During the evaluation process, PERT asks individual estimators to provide three estimates – one optimistic estimate, one moderate estimate and one pessimistic estimate for the same activity.  PERT then averages these three values using the formula, Expected time  =  ( optimistic  +  4 x moderate  +  pessimistic ) / 6.  While I tend to use 3 times the most likely and divide by 5 because I think project variation tends to be greater than 4 times the moderate estimate, I have found PERT’s estimating formula to be a good way to level out the bias.

An Optimistic Ending

Project estimation is almost always fraught with some degree of inaccuracy, so its not as though taking the steps above will result in perfect estimates.  But it is possible to have a reasonably accurate outcome – one that consistently is + or – 10% for the entire project — on a vast majority of projects.   To do this, however, project managers must take methodical steps to reduce innaccuracy.  They must also ask their team members and their senior managers to take off the rose-tinted glasses before giving or speculating on an estimate.

Sensationalism being what it is, I have to admit that I couldn’t avoid leading with nearly everyone’s horror – dead babies.  Yet, there is a critical tie between today’s three attention-grabbing subjects and software development that makes this entry worth reading.  And, it has implications for how you manage your staff, software developers or otherwise, in the days to come.  Read on.

Leaving the Zone

It’s been more time than I care to admit, but during my senior year of college I learned what it means to be “in the zone” as well as what it’s like to leave it – painfully.  A track and cross country athlete at the NCAA Division 1 level, I was the first finisher on my team for my first four races, finishing in the top five for every race and posting two victories.

Old glories aside, it’s far more notable what happened next – my body crashed.  Though I’d trained hard with the rest of my team by posting a full Summer 80+ mile weeks and even two at 100+, I then took on the World when classes started, signing up for a full slate of five courses and tacking on a full time job managing a political campaign in Montecito, California, fifteen minutes south of Santa Barbara.  I slept less than five hours a night and spent nearly all my time racing from one place to another, which is a sure recipe for a wrecked body.

Back then, I had no idea there were limits to the punishment my body could take, but I found out quickly.  After consistent finishes with the lead pack among hundreds of runners, I finished no better than the middle of the pack in my remaining four races.  Even worse, my team went from three victories in four races to middle-of-the-pack as well, in part because I was no longer pacing them to victory.  At the end of the season, the affects of over-work were readily apparent – an MRI showed three stress fractures, one of the femur, our body’s largest and most durable bone.  Clearly, I didn’t recognize when I was “Leaving the Zone” by over-working myself, but had only just come to realize this.

Dead-Tired Staffers

Amazingly, it took an enormous amount of self-abuse for me to finally start listening to the messages my body was sending me about being tired or over-worked, but the lesson has stayed with me since.  As I’ve spent more time at work leading people, I’ve noticed that lesson also to the work world, where tight deadlines and high-pressure work can lead us as leaders to push for overtime again and again.

Consider your last marathon project with brutal deadlines and lots of overtime: Can you remember seeing these signs of over-work in your team members as they pushed themselves beyond their limits:  Irritability; an inability to concentrate; lower productivity; poor quality; at the extreme, negative productivity, when more work was thrown out than is gained?  Looking back, you’ve probably seen at least a few of these, and if you check out your defect logs from the work produced during these times, you’ll notice a spike in the number of defects resulting from your “more overtime” decision.  But, maybe you’re still denying that over-work will threaten the success of your projects, not to mention the long term well-being of your team members, as you run a dedicated team of dead-tired staffers over the edge.

Dead Babies

If this is the case, you wouldn’t be the first manager I’ve met who doesn’t understand how over-work can actually slow your project down rather than speed it up.  Software developers, analysts, engineers and QA team members, these managers argue, are hardly putting in a hundred miles of physical exertion each and every week, though they may be putting in 60 or 70 hours of work.  These managers counter that mental exertion and sleep depravation are not the same as physical exertion on the level of a college athlete. Or, they accept it in theory, until a project falls behind or a key deadline looms.

Though I found a number of excellent articles and blogs on the subject of software development and over-work and I’ve posted at the bottom of this article, the best evidence of the adverse affects of sleeplessness, stress and over-work on our ability to use our minds productively actually comes from the world of parenting.  In the Washington Post article, “Fatal Distraction: Leaving a child in the back seat of a hot car…”, report Gene Weingarten moves beyond the emotion of a very sensitive subject and asks the telling question of what was going on in the lives of parents who leave their children in cars on hot, sweltering days.  The answer?  Stress, sleeplessness, over-work and half-functioning brains – in many cases brought on by us, as managers.

“The human brain is a magnificent but jury-rigged device,” cites Weingarten of David Diamond, a Professor of Molecular Physiology who studies the brain.  (Weingarten and Diamond deserve all of the credit for this research, but I’ll paraphrase).  A sophisticated layer – the one that enables us to work creatively and think critically – functions on top of a “junk heap” of basal ganglia we inherited from lower species as we evolved.  When we over-work our bodies, the sophisticated layer shuts down and the basal ganglia take over, leaving us as stupid as an average lizard.  Routine tasks are possible, like eating or driving to work, but changes in routine or critical-thinking tasks are extremely difficult.  Even the most important people in our lives are forgotten when fatigue and stress are applied, as Weingarten’s article shows.

If an otherwise dutiful, caring parent can’t remember their own child when sufficiently fatigued, what is the likelihood we’ll get something better than a dumb lizard from our software development team when we push them above sixty hours per week again and again?  And when they’re finished, how high will their quality of work actually be?

So, when considering another week of over-time, think twice.  Sometimes, it’s better to just send the team home.

—–

Gene Weingarten’s Washington Post article can be found here: http://www.washingtonpost.com/wp-dyn/content/article/2009/02/27/AR2009022701549.html?wpisrc=newsletter&sid=ST2009030602446

Other good articles on overtime and software development can be found here:

http://xprogramming.com/xpmag/jatsustainablepace/

http://www.uncommonsenseforsoftware.com/2006/06/planned_overtim.html

http://www.systems-thinking.org/prjsys/prjsys.htm

http://www.caffeinatedcoder.com/the-case-against-overtime/

To understand what this means, consider, first, the era when management as profession came into vogue – the industrial age.  The emphasis had shifted away from the craftsman-apprentice model before mass production, where individuals passed on knowledge one-on-one.  Instead, the secret to success in the industrial age was mass production, which required the standardization of business processes and simplification of tasks so that unskilled workers could more easily complete the work.

A manager’s primary responsibilities were to coordinate the efforts of large groups of people, so a highly regimented top-down management style fit best. The 24-hour day was broken down in to two or three shifts, people were assigned to shifts and they generally completed their assigned work. During this age, a manager’s biggest challenges were employees who didn’t show up on time, who left early or who didn’t complete their fair share of work.  A firm hand was required to prevent abuse and keep productivity up; the “manager as boss” excelled in this world and this management approach flourished.

On to the knowledge age, where knowledge is the key tool used to create products as well as the product itself.   For the first time, many products — semi-conductors, computer hardware, software, even modern phones — rely heavily on knowledge as the key inputs to their creation.  In the knowledge economy, the highest single cost in creating the product is the labor of experts – not manufacturing labor or raw materials.  In turn, making the most of the knowledge of these experts is the key to success – not necessarily making the most of their time.

With the shift from industrial economy to the knowledge economy, the storehouse of knowledge and authority are no longer in the same hands.  In the industrial age, the boss knew best; in the knowledge age, you, as a manager, still have the authority, but the knowledge is beneath you, in the hands of the experts.  To adjust for this, a change in management style is needed.

Based on my conversations with respected managers in the age of knowledge and my own experience, here’s how to succeed as a manager in the knowledge economy:

1. Ask the experts.  This sounds simple and straightforward, but it’s rarely followed.  Because many of us are former experts who moved in to management, we consider ourselves experts still.  Yet, how long does it take before our expertise becomes out-dated when we don’t use it?  As little as six months? As much as a couple of years?  Consider this: If your subordinate knows all of the features of the latest version of your software, but you know all the features of the last one, whose knowledge is more valuable?
2. Facilitate – don’t order.  As managers, we all know that the experts around us are extremely bright – in many cases brighter than we are.  How condescending it must seem, then, when we managers order our team members to execute our instructions.  Instead, help them to identify the problems together, then assist in developing a methodical approach for solving it.  In the process, it will become clear which team members should tackle each step in solving the problem.  No orders necessary.
3. Coordinate – don’t control.  As former experts, we’re acutely aware of the challenge of being “stuck in the weeds” – that desire to keep your head down and focused on solving the problem in front of you.  As much as that tendency toward isolation grips our fellow experts, we should coordinate their efforts and encourage them to work together as a team.  Coordinating the team means bringing them together, discussing key challenges and asking one expert to help another to achieve breakthroughs when addressing a challenging problem.
4. Serve as a knowledge bridge.  In many cases, the specialized knowledge of one expert on your team is very different from the specialized knowledge of another.  For example, one person may specialize in database design, while another specialized in user interface (screen) development.  Because of this, they are often working on very different tasks, even though one person’s knowledge may be needed to solve another person’s problems. As the manager of this team, we know what each team member is tackling and we should know whether they have solved past problems.  It’s our job to connect the dots across the work of our teams, to point out patterns in problems that we see, and to bring together the experts to share their relevant knowledge, solving each other’s problems more quickly and efficiently.
5. Set challenging (but realistic) goals.  Knowledge experts like challenges, so work with them to set short term and long term goals that are SMART – Specific, Measurable, Attainable, Relevant and Time-specific.  As part of the process, be certain to set goals to be a little more challenging than the person believes is possible – but not so difficult that the person ignores the goal because he or she thinks it’s impossible.
6. Value the individual.  In the industrial age, the loss of an individual team member was disappointing, but it wasn’t likely to cripple your business, your division or your projects.  In the knowledge age, there are people who are so essential that their departure could force the business to crumble.  While I would argue that it has always been important to treat people well, in the knowledge age, it’s even more important to treat each individual with respect and consideration.

——-

In many respects, the knowledge economy has made managing more challenging.  In many management positions, “people” skills are more important than analytical abilities.  Even more challenging, your position as manager often makes you more expendable than your subordinates.  Combined, it’s critical to your success as a manager to look beneath you for the knowledge and expertise for you and your organization succeed.

Yet distant relatives, friends of mother’s friends, even strangers crash weddings. Why?  Whether we’re single, engaged, married or widowed, we all have something that draws us to weddings, though in each case, the draw is different.

Perhaps we were single at our last wedding, sitting in the audience witnessing the big event. The excitement, the apparent nervousness, the spoken vows, the commitment of two people to each other – they were all so inspiring. And the couple, the glowing twosome – they were called to be better people because they were now bound together till death – and who can’t admire that?

Perhaps at our last wedding we were engaged.  For us, we could anticipate the big day of our own ahead, we imagined ourselves walking the same steps, our voices quivering but hearts courageous, our long, passionate embrace before hundreds, our life ahead.  It was an appetizer. A teaser. A dream.

Or, maybe we were already married at our last wedding.  We remember standing there; we made the vows so we knew what they meant.  We had lived them and if we were honest with ourselves we knew that we had even struggled, at times, to keep them.  For us, there was a level of courage being displayed that only the wedded truly knew.

When we married folk come to weddings, we also recall the beginning of our marriage, the promise we made and the excitement we felt.  We remember all of the great events since then – the first home, the first child, the second child, (the third child?) The first big scare, the first broken bone, the first big fight, the makeup after the first big fight.  We remember all of the good times marriage brings; we comfort in the strength it brings during bad times; and, we celebrate another pair choosing our path, even though we have walked it less-than-perfectly ourselves.

Or,  perhaps we were widowed at the time we attended our last wedding.  We missed our love and the pain was far stronger than it was only hours before the event, but the good memories were also brought forward.  We remember meeting; we remember staring at each other’s young faces in youthful joy; we remember knees and backs that suddenly didn’t bend well to pick up wee ones; we remember plucking the first gray hairs from each other’s heads in stubborn defiance; we remember  admiring each other’s wrinkles fondly like badges of merit.  We remember our first realization that this would one day end. We remember parting.

So, for the single, marriage brings promise and hope that two humans can commit to each other and keep that commitment, though it may be a path we never choose and it may not be right for us.  For the engaged, marriage foretells the future; it helps us to plan and dream.  For the married, it’s reinforcement that the path we’ve taken is a noble one, a good one, a rich one.  For the widowed, it’s a remembrance of life’s rich pageant and how we celebrated its richness.

Maybe that’s the key.  Single, engaged, married, widowed – we’ve all seen it before. Like a classic movie or Shakespearean Comedy, we know how it ends before the first act begins.  The righteous prevail; the evil are foiled; the boy walks off with the girl.  It’s a great story that’s been touching the souls of men and women for thousands of years.

That is why people attend weddings.  No matter which path we’ve chosen, it inspires us.  It keeps us walking our path with renewed hope. And, no matter how rough the road appears ahead, it lightens our steps along the way.