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: , , , , , , , , , ,

Technical debt and causes of software instability

February 7, 2013

“Technical debt” refers to releasing software products that have significant bugs in them.  The cost of removing the bugs after release must be paid if the software is to survive in the long run.  So the concept is similar to financial debt: the longer you leave it unpaid, the more you must pay in compound interest.

In a recent interview, one of the authors of the term “technical debt” had this to say:

Most companies don’t have a clue on how to get rid of bugs before release. … they’re acting out of ignorance because they don’t know what they’re doing. … the companies that do know what they’re doing … don’t have much technical debt … because they’re using … defect-prevention, pretest removal, static analysis and inspections, and really good testing.

– Capers Jones  as quoted by Joe McKendrick http://zd.net/VjuA38

Evidence of technical debt is all around us:  Maintenance efforts that are larger than the development effort on a product suite.  Failures that keep occurring in software that has been on the market for years.

Three false causes for software instability.

1.    Users don’t care

Many products are delivered quickly to an audience that is not very discriminating.  For example, if your iPhone app fails once in a while, you aren’t too disturbed unless the failure causes the whole system to stop.  And if the app allows malware to infect your phone, you probably won’t be able to tell that it was caused by shortcomings in the design of the app.

But in the long run, people will know whether the software is reliable and secure.  So they will drop out from your customer list without so much as a goodbye note.  You have a few months to get your product up to a reasonable level of reliability, but you don’t have years.

2.    It costs too much to do it right

Everyone knows it is impossible to test all combinations of inputs to a software system.  So we depend on educated guesses when testing.  And when a product is behind schedule (and what product isn’t behind schedule?), we short-change the testing in order to meet shipment date commitments.

But even though exhaustive testing is impossible, it is possible to have a well-crafted testing plan and to execute the plan in a timely way.  Yes, this does require budgeting enough resources for testing.  Doing it right saves a lot of headache and lost goodwill later on.

3.    We don’t know how.

There is no single accepted set of standards for how to create bugless software, so why try to follow the latest trends?  After all, even the biggest organizations (the FBI, airlines, banks for example) have had software projects fail to complete.

But there are management techniques, including Agile methods, that can minimize the risk of a failed project.  So there’s little excuse for ignoring the advances that have been made in software development.

Three true causes for software instability.

1.    It’s complex

As more and more products are designed with software at their core, the complexity of the software tends to get greater generation by generation.  This is good, in that the depth of the software leads to more sophisticated solutions.  But it also makes for complex systems that are increasingly difficult to stabilize.

2.    There’s a shortage of experienced and competent leaders

The demand for professional programmers and software designers is great and growing all around the world.  While many people are moving now into software development, the number who have at least a decade of real-world experience is not growing as fast, and many of those who do have not led large-scale development projects.  The gap is not being closed by traditional project managers, because most of them do not specialize in software development.

3.    We’re still experimenting with management methods

Agile development methods are formally only 12 years old.  And there are many competing methodologies out there, none of which has come to dominate the field.  While it is good that many different approaches are being tried, a manager who wants to be guided to the “best” method will receive conflicting advice, particularly from vendors who are each flogging their own piece of development-support software.

Shall we advise them to come back in 20 years, when we’re down to one or two leading approaches?  Not practical, because the development must go on.

If you’re responsible for software development or the products the software goes in, you’ll have to make some choices based on what’s known now.  It’s best to get advice on the methods and the tools, but not to depend on any one vendor to tell you how to proceed.

—————————–

My recent talk at SofTech, 10 Ways to Fail revealed many indicators of failing projects.  Download the slides & notes here.

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: , , , , , ,

Why is it so hard to get good software?

May 29, 2012

Once we get over our wonder at the broad capabilities of software running on modern computers and devices, we begin to ask why so much of the software we use is of questionable quality.  Between vulnerabilities to malware and constant updates to correct problems, it seems that software is never stable and reliable.  Why?

Software is abstract, invisible and runs at very high speed.  This combination of features makes developing software the domain of a special kind of person who can deal with the abstractions and with the incredibly fine detail of software creation.  Managing a group of such people also requires a special kind of talent as well, because there are tradeoffs to be made between getting new features added and stabilizing the functions that are already built-in.

Usually, the pressures of commercial software development lead software marketers to place much more emphasis on new features than on stability, because features are what differentiate one software product from another.  However, the long-term stability of a product also contributes a lot to the product’s reputation.

Software testing is the usual way to verify proper functioning before shipment.  But since software development routinely takes longer than anticipated, it is the testing that gets short shrift in many cases.  The result is premature delivery of software that is not yet ready for commercial use.

A 2002 study commissioned by the National Institute of Standards and Technology found software bugs cost the U.S. economy about $59.5 billion annually. The same study found that more than a third of that cost — about $22.2 billion — could be eliminated by improving testing.     http://on.msnbc.com/Kae58w

In addition, the operating context of software is constantly changing.  As operating system upgrades are released, the software that works under that operating system often must be adapted to the upgrades.  This means that a lot of the work of keeping a software package current goes to merely maintain the capabilities that were already built.

Users continue to ask for new features.  And marketers want the software to be useful in more contexts – such as making an app useful on an Android phone in addition to an iPhone.  These demands guarantee that a software package will always have an endless backlog of potential changes in the “to-do” list.

As more contexts are supported and more features are added, the software inevitably becomes more complex.  And complexity multiplies the difficulty of testing, and also makes each change to the software riskier.  The more interactions that are possible with each part of the code, the more possibilities there are for mistakes.

What can I do to help make software better?

Purchasers of software don’t have very high expectations, because the track record of the software industry does not set a very high bar.  If users demanded better software and rejected poor software, software vendors would provide better packages – or go out of business.  Why don’t we demand better software?

One reason is that it is hard to switch.  Once we have adopted a piece of software for some function, we tend to stay with it.  First of all, it’s what we are familiar with.  This “makes us rather bear those ills we have than fly to others that we know not of.” [Shakespeare – Hamlet]  The cost of learning a new system is high, and we tend to stay with what is familiar, even if it is painful to use.

Second, the vendors of software don’t often make it easy for us to switch to another vendor.  Try taking an Access database and “porting” it to FileMaker Pro.  The conversion process is a barrier that most of us are unwilling to undertake.  In addition, there may be many people who need to be trained in the new system if we switch.  That adds to the cost.

In the future, we should look at the cost of switching before committing to a software vendor or cloud system.  The more “open” the system, the better for us in the long term.

And we should always insist on demonstrably high quality in software.  Keep this in mind the next time you’re making a purchase decision.

 

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

Success always looks easy

March 13, 2012

With all the news about IT projects that go bad, you would think that we’d hear more news about projects that go well.  Then we could just copy down the “best practices” that led to the success and – voilà – our projects would come out perfectly every time.

But life is not so simple.  While we can enumerate key problems that led to failure by analyzing projects, it is much harder to point to one factor and say “this is what made this project successful.”  Success depends not only on avoiding the pitfalls, but also on bringing together all of the essential project elements.  Sometimes those elements are not so easy to identify.

Example 1:  I once struggled for 7 months with a project team that couldn’t seem to get all the right pieces together.  In fact, what was needed was to remove two members of the team.  One of them was in a key contributor position, but was just not disciplined enough to produce his part of the code (this was a firmware team).  The other was simply not contributing to the team because he didn’t understand his role and was not capable of fulfilling it.  While I had recommended the removal of these two on my 3rd day on the project, I had not insisted, and the result was a long slog.

What happens when you remove non-contributors from the team?  First of all, someone else on the team steps up to do what needs to be done.  Second of all, the whole team becomes more productive (and happy) because they are no longer saddled with the unproductive members.

Example 2: A client company launched a transition to Agile development methods in the development of a major sales-support package.  They hired an experienced team of software people and an Agile coach.  The program went well.  I was asked to assess the team and the project during its first year.  My assessment:  this team will do well no matter what methodology they use – because they are experienced people who know how to work in a team.

There was also an invisible success factor, invisible to the remote business people who chartered my assessment.  Within the ranks of IT management was an individual Director-level manager who secretly supported the Agile transition.  I say “secretly,” because the CIO turned out to be opposed to any special treatment of software developers (compared with, say, treatment of call-center operators), let alone “Agile” teams.  This manager quietly encouraged the Agile team and provided me with insight into all of the IT department politics that could affect the team’s performance.

If you manage to identify and engage the key success factors in real projects, you’ll be regarded as a genius.  But don’t let it go to your head, because a lot of it is luck.  Luck that is aided by keeping your eyes and your mind open.

If you’re managing a major project, it’s best to call upon resources (not just people, but information or equipment or software) that help compensate for any shortfall. So it’s a good idea to continually build up your network of contacts, your access to information, and your knowledge of available equipment and software.  Then, when you run into a roadblock, you can call on your network to help find what you need.  And of course, it doesn’t hurt to have a secret ally in the management ranks.

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