How to manage a project

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.

Software development – not by PERT alone

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.

Software Development – not by PERT alone

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

No silver bullet

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.

 

When you need IT advice

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

 

What’s different about mobile apps?

The adoption of smart phones across a wide cross-section of the world has opened up a new arena for business application software: mobility.  This article outlines what’s different about mobile “apps” – and what remains the same as desktop PC software.

Small screen

In the world of media (such as movies), the big screen is in a movie theater, the small screen is a television set, the smaller screen is on a PC, now the tiny screen is on your mobile phone.  While you may be able to watch a movie on a mobile phone, you can’t expect to interact with business software the same way on this tiny screen as you do on a PC.

On the other hand, you’re not always sitting in front of your PC.  But your mobile phone is nearly always at hand, so this makes it attractive as an “always on” device that you can use for interacting with your business.

Since the introduction of the Apple iPhone, the underlying operating system software of the smartphone has had nearly all of the capabilities of a PC operating system, with one exception:  only one app can run at a time (up to now).

Aren’t mobile apps and PC applications the same?

Some characteristics of apps are the same as for PC.  For example, apps must be developed to match the specific operating system found in the smartphone.  This means that a iPhone app has to be deliberately designed for the Apple IOS system, an app for a Samsung phone has to be designed for the Android system, and so on for Nokia and Blackberry apps.

The people who develop apps have to use a development environment (a bunch of software tools) specific to the target OS, or else use an environment that is “cross-platform,”  so that their resulting app is adapted to the target OS.  There are many of these cross-platform tools.  If you’re interested in them, see http://en.wikipedia.org/wiki/Mobile_application_development .

Other restrictions

Each target operating system may have other restrictions, such as the requirement that all apps for the iPhone be reviewed and approved by Apple.  This makes the job of the developer harder if he is trying to make an app that runs on any phone.

A mobile app is software that runs on the phone and uses the underlying operating system to perform certain functions, such as interacting with the user and communicating with a website or the telephone system.  Some of the functions available in a smartphone are unique to the mobile environment, such as being able to find out where the phone is right now from the GPS.

Browser-based interactions

Just as with a PC-based user, one way to implement business functions is to use a browser to access a server offering the functions.  In fact, a server can implement both PC and mobile versions of its user interface in order to offer the same – or nearly the same – features to both PC-based and smartphone-based users.

One of the current developments in browsers is the HTML5 language, which allows a single software package to offer adaptable results that can make mobile/PC apps easier to move around to different phones and/or PCs.

Of course the designer of the user interaction has to be aware of the size of the screen.

What about security?

Whether an app is PC based or smartphone based, security is still an issue.  And moving the functions into a browser-based app in a server does not take care of all the security issues, either.  We’ll take up the question of security in a future blog entry.

 

For more information about app development, here’s a link to one of the commercial companies that do mobile application development.