Donald J. Patti

Posts Tagged ‘leadership’

From Chaos to Crisis to Calm – 9 Tips to Recover Troubled Projects

In Business, Entrepreneurship, leadership, management, project management, Small Business on 8 February 2010 at 9:00 am

Dan Moore, a fellow Principal at Cedar Point Consulting, recently reminded me that, “You can’t manage chaos, but you can manage a crisis.” These are very wise words, but they reminded me of the early stages of a trouble project — one which is far behind schedule, well over budget, not delivering results, or all of the above.  If anything, a troubled project is chaos waiting for a strong leader to transition it to crisis, and then ultimately to calm.

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.

Advertisements

Failed Pilot? Chalk it up as a Win!

In Business, E-Business, management, project management, Software Development, Technology on 14 December 2009 at 8:30 am

You’ve just had a failed pilot, followed by a quick meeting with the Project Management Office (PMO).  Your project was killed and you feel like a failure.

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.

When Taking Over Means “Steady as She Goes”

In Business, leadership, management, project management, Small Business on 15 November 2009 at 8:00 pm

You’ve taken a new leadership position, so you’re ready to take charge and make your mark. There’s just one problem – all’s well. The division you’ve inherited is running smoothly, or the project you’ve taken over is on target. What do you do? Here’s how to tell you’re in this leadership situation, and what to do if you are.

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.

Dead Babies, Dead-tired Staffers and “Leaving the Zone”: Exceeding the Envelope in Software Development

In E-Business, Ethics and ideology, management, Quality, Software Development, Technology on 12 October 2009 at 10:38 am

I know, I know.  “What do dead babies have to do with software development?” you say.  “Are you playing my heart-strings?”

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/