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

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

When you need IT advice

September 25, 2012

When you ask for advice from an IT specialist, often the response is too technical, too closely tied to a commercial product, or simply off the mark because the underlying problems are management problems.  Who can you turn to for useful and practical advice?

What kind of technology advice do you need?

As a manager or executive you may have a variety of questions about “technology.”  Here is one way to classify those questions:

1. Pure technical analysis – what’s possible, what does it cost?

You already have a clear idea of the functions or capabilities you need.  But now you need to know what technologies can be used to get those functions, and what they are likely to cost.   An IT specialist with experience in building those functions can elaborate the technologies and give you a roadmap for building what you want.

If the specialist also has enough experience, you can get a fairly accurate estimate of how much it will cost – if things go well.  But always be prepared for bumps in the road.  Many time, due to evolving technologies, unforeseen glitches due to incompatibilities, and changing requirements, the costs will go up – even as much as doubling the initial estimates.

The best countermeasure to escalating costs is to define incremental delivery of the features.  Ask for demonstrations and delivery of working systems every few months, so that you can personally verify that things are on track – and that you’re getting what you want.

 

2. Help in selecting between competing alternatives – evaluating vendors and their products/services

When the times comes to select a vendor or to choose a team for building the capabilities you want, ask for help from someone who has done it before.  In other words, make sure the advice you get is from someone experienced in the particular functions and capabilities you’re asking for.

Be sure that your advisor is not “married” to a particular vendor.  Of course, this eliminates the sales representatives of the vendors from being the advice-givers you need.  Even your own IT staff may have prejudices based on their own history and experience with particular vendors’ products.  You may want to find a consultant who knows the field and can give you accurate information without being involved in the sale of a product.

Evaluating vendors also includes business aspects.  You need to know that the vendor will survive to support the product, has the infrastructure needed to provide what you need, and is willing to commit to meeting your service standards, whatever they may be.

 

3. Guidance in managing the implementation of new IT services

Once you’ve committed to implement a new capability, you form a team to carry out the project.  At this point, you may need help in assuring success of the project.

Projects fail all too often.  Most failures are due to one of the following:

•  Inadequate planning and scoping of the project

•  Unrealistic expectations about what can be done in what time

•  Unadequate management structures for coordinating the project

•  Unforeseen complexity and rapid change in the requirements

Hiring an experienced management consultant can insure you against project failure for a small fraction of the project cost.  You’ll want to find someone who speaks in business terms, has management experience, and knows technology well.

This third area — managing implementation — is the area in which I work.  I’ll be glad to offer you a free strategy session in which we examine your project and your plans in an initial consultation, to see if I can help raise your confidence that your project will succeed.  Simply contact me by any of the methods below.

 

SUBSCRIBE FREE: https://johnlevyconsulting.com/blog

Just complete the simple form. Takes about 10 seconds. And you’ll also get a free copy of my report, “9 Mistakes That Lead to IT Project Failure.”

 

John Levy Consulting                                415 663-1818

Deliver the promise of technology to business

https://johnlevyconsulting.com

PO Box 1419                  Point Reyes Station, CA 94956

 

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

Why isn’t software more secure?

August 13, 2012

What makes software insecure?

Software is often insecure because it is complex, abstract and not completely understood even by the people who create it.  A software specialist who designs a human interaction module may not know much about the database software that the module depends on, for example.

In addition, software runs in a hardware environment (the computer system) that is not completely known by the creator of the software.  For example, when a software package is designed to run in a Microsoft Windows system, the hardware may have been manufactured by any of a dozen companies, each of which has its own detailed hardware environment (including things like BIOS, memory, storage, and input/output subsystems).

And the software itself has to keep changing to keep up with user expectations.  Software that doesn’t get updated gets stale.  [See more about this in my previous blog: stable or static]:

What vulnerabilities are there in software?

Software is vulnerable to many possible conditions that it may not be prepared for.  For example, unexpected inputs can lead to errors: if the software is expecting a number and it gets a value that is outside of reasonable bounds, it may have unpredictable consequences.

In addition, computer hardware can have exception conditions occur during instruction execution, such as dividing by zero.  These exceptions must be anticipated by the software, or else the program can simply terminate without finishing its work.

For example, one of the popular ways for hackers to break into computer systems is to create a “buffer overflow condition.”  If the software does not anticipate this condition, the computer can execute code that the hacker put into a data structure in advance, causing the computer to come under the control of the hacker.

Why are they always discovering new holes & vulnerabilities in our software and systems?  Doesn’t testing take care of these problems?

Proper testing can reduce insecurities and other bugs.  Often, software development organizations simply don’t use the best tools for testing.  But testing every possible case is impossible.  Testing has to be done using human judgment to decide the testing strategy.

[For an excellent exposition on this subject, see Gerald Weinberg’s book, Perfect Software]

Often the failure to do adequate testing is the fault of management.  When a software development project is behind schedule, the temptation to short-change the testing is very high, because testing is usually tacked on to the end of the development cycle.

[For more on this, see my previous blog: good software]

How else is software insecure?

Most software does not run in a vacuum.  Often it is interacting with a human operator.  When a program and a human are interacting, there are plenty of opportunities for misunderstandings.  For example, error messages may be confusing, or the human may take the wrong action in response to a warning message.

The people who make it their business to take advantage of software vulnerabilities – call them hackers or attackers – are becoming more sophisticated.  They may be after money or industrial secrets, and they often know a lot about the system and the person who is interacting with the system.

A whole class of attack, called spear-phishing, is based on deliberately showing misleading information to the human, such as an email that appears to come from the person’s boss.  Vulnerability to these attacks occurs both in the system (email delivery without validation) and in the person (accepting what appears at face value).

What’s an enterprise to do about insecure software?

As a first step, make sure that you have engaged security specialists – people who have studied and are expert in attacks and in security countermeasures.  The specialists should include “white hat” testers – people who deliberately try to break into your own systems in order to demonstrate vulnerabilities.

You should also ask questions of your project managers about tradeoffs being made between testing and quality.   You must recognize that when you choose to emphasize schedule, you often invite lower quality and therefore higher vulnerability.

Never assume that software is of high quality – and therefore invulnerable – until you have seen it demonstrated in actual use by real users.  And even then, expect to find vulnerabilities regularly, and be ready to fix them.

 

TO SUBSCRIBE FREE: https://johnlevyconsulting.com/blog

Just complete the simple form. Takes about 10 seconds. And you’ll also get a free copy of my report, “9 Mistakes That Lead to IT Project Failure.”

John Levy — Turn Around IT
      Helping business get full value from IT

https://johnlevyconsulting.com

PO Box 1419, Point Reyes Station, CA 94956    415 663-1818

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