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

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

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

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

Eliminate your IT department?

September 10, 2012

Cloud-based services are transforming business IT in major ways.  What does this mean for the structure and mission of the enterprise’s IT department?  Is there anything left that can’t be done by the cloud and by cloud service vendors?

Yes!  There are three major areas in which every enterprise still needs a collection of people who focus on IT.  And it is best to have them gathered in a department where they are able to exchange information at high bandwidth – in other words, in an IT department.

1.    Expertise

While it can be advantageous to place IT specialists inside of business departments where they can advise their business counterparts on specifics of applications, data and cloud services, keeping up with the range of IT offerings is a job best done at a central location.

Building a center of expertise will enable IT specialists to respond to requests from business units for recommendations and advice on cloud vendors, facilities and functions of various IT packages, and general information on what solutions are now available.  In addition, the experts can create informative newsletters and workshops on what’s around the corner, the progress of corporate IT initiatives, and other current IT topics.

This type of dissemination of information cannot typically be done as well by department-captive IT specialists.

2.    Strategy

Your business has a business strategy.  Almost certainly, that strategy depends on certain IT initiatives.  Defining, aligning, and guiding those initiatives must be done by people who understand the business strategy and also understand IT deeply.  These people should be IT experts who also are involved in strategic planning for the business.

As a result, they are strategists for IT as well as for the business.  So they need to keep up with the latest trends and possibilities in IT as well as know a lot about all of the enterprise’s current IT implementations.  These people are natural members of a central IT department.

3.    Management

IT management involves several different perspectives.

First is managing the IT-business interface across all IT initiatives and across the functional components of the business.

Second is managing the IT department and its initiatives, including developing, training and promoting IT specialists.

Finally, there is management of vendors, including cloud service vendors – and increasingly crucial portion of the management workload.

All three of these aspects of IT require an IT department – or an equivalent – that concentrates IT expertise and IT-related missions into a place where communications are very frequent and easy.

Don’t eliminate IT, transform it

As cloud-based services begin to transform the way in which IT functions are accomplished, the IT department should concentrate on developing its expertise in the following areas:

Cross-connecting siloed business functions and helping to eliminate duplication in IT activities and services.

Teaching, training and informing business leaders about IT, including which cloud-based services can best help get their jobs done.

Monitoring, measuring and rewarding vendors who are supporting business functions in the enterprise.  This includes setting standards for performance, helping with contractual arrangements with vendors, and monitoring both positive performance and negative incidents surrounding IT vendors.

Creating IT strategic plans, including corroborating those plans with enterprise strategies and plans.  And finally, adapting the enterprise to the rapidly-shifting cloud services environment.

In other words, there’s plenty left to do in an IT department.  Don’t eliminate it.

John’s webinar titled will be held on September 25 at 10:00 AM Pacific time.

Designing, implementing and integrating major IT systems has numerous pitfalls that don’t appear, for example, in building construction. If you’re responsible for delivering a major IT project – or if you are paying for one – you need to be aware of what indicators are red flags for possible failure of the project.

See more information and register at 

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

Deliver the promise of technology to business


https://johnlevyconsulting.com

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

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

How to generate team energy

July 23, 2012

If you lead, manage or work with teams, you know that teams have their highs and lows, just like individuals.  Energy is a quality of the interactions going on in the room the team is working in, a quality that you feel when you’re in the room with them. The energy of a team is a key indicator of how well the team is functioning.  Here are things you can do as a leader to generate positive energy.

There are a variety of types of energy.  A team may have intensity caused by anger or by competitiveness; or it may have high enthusiasm expressed by outbursts of joking and fun.  There may be quiet most of the time, interspersed with interactions that express appreciation or admiration (the wow! factor).   Or there can be a sullen tone in a team that resents its mission or its management.  Sometimes, a team pulls itself together and generates camaraderie because it is facing a common enemy – often represented by its management.

The energy of a team is a good predictor of its effectiveness.  The best teams have at least occasional bursts of intensity, and they maintain respectful, if joking, relations with each other.

As leader of teams, part of your mission is to sense the energy of the team and to intervene when things are not going well.  Unhealthy interactions are an early predictor of decay in a team.  You should be ready to make necessary adjustments when you see things unraveling.

Here are two things you can do to keep team energy positive:

1. Embrace & appreciate diversity.

Most teams we work with have people from diverse backgrounds.  Rather than cover over the differences in culture and style among the team members, call upon those differences in an appreciative way.  For example, if one of the team members comes from a culture, such as Japan, the Philippines or Thailand, in which harmony is the supreme value, ask that person review the team’s interaction ground rules.  While many Americans relish confrontation and argument, others may prefer that the ground rules keep them from having to argue in a contentious way.

You should encourage everyone on the team to call on members who typically have different views to get feedback about a proposed technique, method or solution.  In this way you help the team to revel in diversity and appreciate their differences, rather than viewing differences as being in the way.

2. Hear all the voices, trust the team

A few years ago, I was facilitating a team of business and IT specialists who were working to overcome their history of finger-pointing and frustration with each other.  We had a dozen people in the room, and they quickly took to the task of listing what was working, what was not working, and prioritizing the actions to fix their dysfunction.  As the process entered the second full day, I noticed that one person had not yet said anything during the group work.  I began to wonder why the leaders had included this person.

Normally I would go out of my way to be sure that everyone’s voice is heard, no matter how briefly.  However, in this case I let the process continue without intervening.  Several hours into problem-solving, the team was looking for ideas to deal with how to communicate certain technical details between their offices, 750 miles apart.  Suddenly, the previously quiet person spoke up with a proposal.  The suggestion was brilliant, and the team quickly adopted it.  The lesson for me was to trust the team and the process – the leaders knew this person had something to contribute, and they knew he would speak up when he had something to say.

You have a responsibility to guide the energy of the team.  You can do this in a positive way by doing these things:

a.     Create a common space – common ground – where the team can interact informally, even if they do not inhabit a common room when they’re working.  This is where they can trade stories, post items of interest on the walls, and find out what’s going on with the team.  Put key information there, but leave a lot of room for their own preferred items.

b.    Set the tone for the team by being a good listener, appreciating the work of each individual, and providing honest feedback about what you observe.  Don’t indulge in disrespectful humor or gossip.  And keep your own energy up, so that you don’t need to draw energy from the team.

c.     Get out of the way.  Most of the team interactions don’t need your guidance.  Check in with what’s happening at various moments through the day or week, but don’t try to guide everything.  If you give your team permission to try out and adopt processes that aren’t necessarily pre-defined, they’ll generate their own enthusiasm and will often surprise you with their creativity.

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