How to manage a project

August 6, 2013

The essentials of project management in under 500 words

What’s a project?

A project is any endeavor that takes time and involves more than one person.  Typically, we don’t call it a project unless it involves at least 3 to 5 people, and then we call them a team.

A project requires communication, collaboration and coordination.  A project also usually results in something being delivered to a third party.

Five aspects of managing a project

1. Defining the parameters.

What are the inputs?  What are the outputs?  What are the rules?

2. Discovering the goals, limits and values.

Goals include requirements for the outputs and other things that you want to have as a result of the project.

Limits include things like how much money you can spend, how much time you have, and who is allowed to do what.

Values include the priorities among time, cost and quality; and what the people in the project want to get out of it.

3. Planning the work

Planning includes setting your own expectations and the expectations of others; and being prepared to deal with unforeseen events.

4. Reporting

Reporting means communicating about progress, problems, resources used, and results delivered.

5. Interacting

Interacting with team members and stakeholders to facilitate, encourage and moderate.

What is a successful project?

A successful project delivers the right outputs on time.

At the end of a successful project, the team is still improving and is ready to take on another project.

At the end of a successful project, we have learned something and improved how we define, discover, plan, report and interact.

How do projects fail?

A project that produces no output or produces the wrong output is a failure.  Examples include products that get returned or software that causes problems for the customer.

A project that consumes excessive resources is a failure.  A project that does not deliver results in time to be useful or valuable is also a failure.

A project that ends with a burnt out team who cannot take on another project is a failure.

How to head off failure?

Choose and keep the right team.  Select people who have needed skills and are good at being part of a team.  Remove people who don’t get along with the team.

Limit the scope of the project.  Put your job on the line to keep the project down to a manageable size.  Break the project into phases to limit the scope of the current work.

Verify correctness of the outputs with the customer.  Check the requirements with the stakeholders at the beginning, and verify regularly that what has been done is still needed and expected by the stakeholders.

Iterate at regular intervals.  Deliver workable parts of the output in small increments and then re-check the scope and priorities for the next increment.

Listen carefully at all times.  Don’t presume anything without verifying it yourself.  Tell people when they’re doing something right.

 

 

Interested in tiny houses?  See Tiny House Design Workshop for a September event in Washington, DC.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , ,

Software development – not by PERT alone

April 1, 2013

I have great respect for software developers.  Because software is abstract, invisible and runs at extreme speeds, the people who are good at building it have to possess a particular talent at visualization and a willingness to use complex tools.

When software developers become project managers (PMs), they tend to rely on software tools to monitor, control and report on projects, just as non-technical PMs do.  The problems that technologists have in management have to do with inexperience in people interaction, including conflict, collaboration and just plain old ability to listen well.  If you’re a technologist in management, you can find more ideas on what to do about this in my book Get Out of the Way.

For the rest of PMs, there are lots of good tools, such as PERT and Gantt charts, but simply having good tools will not make your project succeed.  Software development projects frequently fail to produce results that the customer or end-user wants.  Why?

Here are three factors that contribute to the unruliness of software development projects:

  • Estimating the effort and time required to complete a task is difficult.  Even when reasonable-looking requirements and specifications of a software package are provided, understanding the difficulty of development may require architecting multiple layers and investigating interactions with a complex environment.  Since requirements are generally high-level items, and design has to be done at multiple levels, it is difficult to break down the work into “pebble-sized” tasks and then to keep to a schedule with those tasks.
  • Designing an algorithm often takes experimentation.  Engineering a software system requires trying out some things to see if they work, or testing multiple possible ways to implement something to find one with reasonable performance, for example.  This aspect of software engineering is so prevalent that Fred Brooks in The Mythical Man-Month advised us to “plan to throw one away.”  He meant that at the completion of a complex software implementation (such as an operating system), the designers have learned so much that it is often best to start over and re-implement everything.
  • Assuring that a software implementation functions properly under all conditions may take as long as the design phase.  In fact, you may never be able to prove proper functioning, because testing all combinations of conditions is impossible.  At best, using test-automation tools and good intuition about where to look for errors, a software team can reduce the number of bugs at the time of a software release, but almost never to zero.

Scheduling a software project is made more difficult by the fact that additional tasks are always discovered during implementation.  This is so prevalent that I learned long ago always to ask “What remains to be done?” in addition to “What have you completed?”  You can count on the list of tasks to be done growing during the project.

One of the best countermeasures to all of these problems is to use Agile development methods.  Using iterative development with regular demonstrations of working software having incrementally greater functionality will help reduce uncertainty and increase the ability of a development team to adapt to a changing world.  It also shortens the time between the initial charter of the project and the point where the customer says, “but that’s not what I wanted.”

Even Agile will not save all projects.  To learn more about why not, have a look at these slides, “Why Agile Won’t Fix All Your Problems.”

And good luck.  The world needs software, so we all have to keep on trying to deliver it the best we can.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , ,

What’s wrong with complexity?

March 19, 2013

We tend to design things that are complex, and that can be our undoing.

 

Technologists love intricate mechanisms.  That’s why many of us, as kids, took things apart, and some of us even put them back together again.

In my training as an engineer, I enjoyed learning how mechanical, electrical and chemical things worked.  And the more elaborate the mechanisms, the better the challenge and the satisfaction of getting the understanding.

We tend also to design things that are complex, particularly if we’re in software design, because software is layered into abstractions almost without limit.  Database systems linked via networks to computational engines and on to user-interaction devices are full of opportunities to exercise our power of design in the face of complex interactions.

Yet complexity can also be our undoing.  Consider this from Andre Zolli’s article about the crash of Air France Flight 447:

It was complexity, as much as any factor, which doomed Flight 447. Prior to the crash, the plane had flown through a series of storms, causing a buildup of ice that disabled several of its airspeed sensors — a moderate, but not catastrophic failure. As a safety precaution, the autopilot automatically disengaged, returning control to the human pilots, while flashing them a cryptic “invalid data” alert that revealed little about the underlying problem.
 
Confronting this ambiguity, the pilots appear to have reverted to rote training procedures that likely made the situation worse: they banked into a climb designed to avoid further danger, which also slowed the plane’s airspeed and sent it into a stall.
 
Confusingly, at the height of the danger, a blaring alarm in the cockpit indicating the stall went silent — suggesting exactly the opposite of what was actually happening. The plane’s cockpit voice recorder captured the pilots’ last, bewildered exchange:
 
     (Pilot 1) Damn it, we’re going to crash… This can’t be happening! 

 
     (Pilot 2) But what’s happening?
 
Less than two seconds later, they were dead.  …
 
We rightfully add safety systems to things like planes and oil rigs, and hedge the bets of major banks, in an effort to encourage them to run safely yet ever-more efficiently. Each of these safety features, however, also increases the complexity of the whole. Add enough of them, and soon these otherwise beneficial features become potential sources of risk themselves, as the number of possible interactions — both anticipated and unanticipated — between various components becomes incomprehensibly large.          [Want to Build Resilience? Kill the Complexity by Andrew Zolli, 9/26/2012]
 

This is certainly a cautionary tale about messages that don’t convey important meaning.  But it’s also a warning about interactions that were designed but couldn’t be tested or evaluated in all their combinations.  That’s what complexity leads to.

Disasters like Flight 447 nearly always require a complex system interacting with a human.  Remember the key learnings of the Apollo disaster: NASA’s safety analyses were not being followed up because of a dual-agenda management system.  The bottom line was that they relied on the fact that heat-shield tiles had never yet caused serious damage.

When you’re responsible for a project that is complex, you need to address that complexity in two ways.

First, you need to be sure that the people doing the analytical and design work know what the possible failure mechanisms are, how to compensate for them without adding a lot more complexity, and have scheduled adequate tests to validate the robustness of the design.

Second – and this is the more difficult – you have to be sure that the people implementing the project and the people managing the project (including yourself) are not harboring private agendas that may undermine the effectiveness of the analysis and design and testing.  Adding ship-date pressure on a team, for example, can cause them to short-change the test plan and declare a product ready to ship when it still has serious faults.

The second area is where your experience with people doing projects will help you most.  Listening a lot to project team members and following up on hints of conflict over goals or processes will help you stay current on the health of your project.

Finally, you can become an advocate for simplicity.  When faced with a choice in a project between a more complex solution and a simpler solution, go for the simpler one.  Often this will allow you to discover sooner whether or not the solution is adequate.

Some projects, of course, become excessively complex no matter what you do.  This may be a time when the most responsible thing you can do is recommend that the project be cancelled.  Better to have no product than one that kills.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , , , ,

Software Development – not by PERT alone

January 21, 2013

I have great respect for software developers.  Because software is abstract, invisible and runs at extreme speeds, the people who are good at building it have to possess a particular talent at visualization and a willingness to use complex tools.

When software developers become project managers (PMs), they tend to rely on software tools to monitor, control and report on projects, just as non-technical PMs do.  The problems that technologists have in management have to do with inexperience in people interaction, including conflict, collaboration and just plain old ability to listen well.  If you’re a technologist in management, you can find more ideas on what to do about this in my book Get Out of the Way.

For the rest of PMs, there are lots of good tools, such as PERT and Gantt charts, but simply having good tools will not make your project succeed.  Software development projects frequently fail to produce results that the customer or end-user wants.  Why?

Here are three factors that contribute to the unruliness of software development projects:

1.     Estimating the effort and time required to complete a task is difficult.  Even when reasonable-looking requirements and specifications of a software package are provided, understanding the difficulty of development may require architecting multiple layers and investigating interactions with a complex environment.  Since requirements are generally high-level items, and design has to be done at multiple levels, it is difficult to break down the work into “pebble-sized” tasks and then to keep to a schedule with those tasks.

2.      Designing an algorithm often takes experimentation.  Engineering a software system requires trying out some things to see if they work, or testing multiple possible ways to implement something to find one with reasonable performance, for example.  This aspect of software engineering is so prevalent that Fred Brooks in The Mythical Man-Month advised us to “plan to throw one away.”   He meant that at the completion of a complex software implementation (such as an operating system), the designers have learned so much that it is often best to start over and re-implement everything.

3.     Assuring that a software implementation functions properly under all conditions may take as long as the design phase.  In fact, you may never be able to prove proper functioning, because testing all combinations of conditions is impossible.  At best, using test-automation tools and good intuition about where to look for errors, a software team can reduce the number of bugs at the time of a software release, but almost never to zero.

Scheduling a software project is made more difficult by the fact that additional tasks are always discovered during implementation.  This is so prevalent that I learned long ago always to ask “What remains to be done?” in addition to “What have you completed?”  You can count on the list of tasks to be done growing during the project.

One of the best countermeasures to all of these problems is to use Agiledevelopment methods.  Iterative development with regular demonstrations of working software having incrementally greater functionality will help reduce uncertainty and increase the ability of a development team to adapt to a changing world.  It also shortens the time between the initial charter of the project and the point where the customer says, “but that’s not what I wanted.”

Even Agile will not save all projects.  If you’d like to learn more about why not, download the slides and notes from my webinar, ” Why Agile Won’t Fix All Your Problems.”

And good luck.  The world needs software, so we all have to keep on trying to deliver it the best we can.

jlcLogo-Lg

Filed Under: Agile Management, Painless IT Tagged With: , , , , , ,

No silver bullet

December 10, 2012

Software is in everything and we and our businesses depend on it more and more.  Yet Software Quality is not rising, so we have rising numbers of failure incidents and out-of-control costs in maintaining software.  What should you do about it?

Software, software, software

No matter where you look, there is software.  Whether you inspect the thermostat in your home, look at the smartphone in your pocket, or lift the hood of your car, you find digital chips running software that keeps the device going.

And this doesn’t even begin to describe all the software that is running in your computer and in The Cloud.  Software is everywhere and we are dependent on it for so many things in our daily lives.

If you have something to do with creating software, you’re probably in a secure job because software creation is not going away.  On the other hand, you’re probably worried about keeping up with the latest techniques and standards, because software development is in the public spotlight more and more.

Why?  Because software failures, system data breaches and rising maintenance costs are in the news more than ever.

Software can be stable and reliable

I attended this month’s meeting of an organization called SofTech and enjoyed hearing Fred Davis talk about the latest gadgets – which, of course, are full of software.  And in that room were some of the most experienced software developers in the San Francisco Bay Area.  Yet even among those high-tech gurus there is an unspoken acknowledgement that software quality is not very high overall, and that creating stable and reliable software is an arduous undertaking.

How can we make it less arduous?  Well, as Fred Brooks explained, there is no silver bullet — no single countermeasure that will make software development become predictable and reliable.  If you want reliable software, you have to organize and execute deliberately, monitor the results regularly and keep up with the evolving tools and methods that incrementally make the process better.

To learn more about development issues, have a look at Technical Debt.  Also visit SEI, PMI, and CISQ.  But above all, get expert guidance that is not focused solely on technology and tools, because creating reliable software depends as much on management and organization as it does on tools and process.

If you’re managing development projects …

I’ve started offering a series of webinars on managing development projects.  The first two were titled The 10 Danger Signs of a Failing IT Project and How to Fix a Failing IT Project.  The third one, in January, will be Why Agile Won’t Fix All Your Problems.

Even these webinars won’t fix all your problems.  But you may become aware of the possibilities and some of the pitfalls in development.  And that could be enough to get you on a path of improving the software quality in your enterprise.

 

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , , , ,