The Project Manager

Big undertakings involving many individual activities and many individual people need some form of management to organise and direct the works.  Without this management, everything will just sit around and nothing will be accomplished.

What is needed is a project manager.  This  person’s job is to:

• Ensure clarity of purpose – why are we undertaking this project?  What is the vision for the project?  What is it expected to deliver?
• Identify constraints – is there a budget we are aiming for?  Is there a timeframe?
• Determine what needs to be delivered and the activities required – what do we need to deliver to accomplish the purpose of the project?  What activities need to be undertaken to deliver what we need to deliver?
• Determine the dependencies between activities
• Identify what resources are needed to perform the activities – resources include skills, material, equipment, and so on
• Procure the resources
• Plan the activities – generate a work plan that respects the dependencies between tasks, respect the available resources, and when executed deliver the deliverables.  The result is a schedule of work.
• Determine the risks that the project face, and plan countermeasures
• Determine how much the project will cost
• Determine the cash flow requirements of the project – how much does the project need on a monthly basis?
• Execute the plan
• Monitor and control the plan

This list of activities is roughly linear, but they will be performed in an iterative fashion because the activities depend on each other.  The plan determines what resources we need, but what resources are available determine the plan we can have.   The target timeframe determines the schedule of work, but the schedule of work determines the timeframe as well.

The Essence of Agile

How much of Agile practices can you remove before it becomes no longer Agile?

I was having a discussion that other day with another project manager, and this fellow was saying that he didn’t think you could do Agile without having a card wall.  Now, I’ve done Agile development before using just an Excel spread sheet instead of a card wall to track the progress, so I know for a fact that you could do Agile without the card wall. 

So I said I disagreed and we left it at that.

A little while later, I thought about the matter a bit more and decided that I haven’t changed my mind.  It is not the card wall that determines if you are doing Agile or not.

Let me give an analogy.  The other week my 6-year old son and I were playing basketball.  We weren’t in any basketball uniform.  I was in jeans, and he was in his civvies. We were still playing basketball, weren’t we?

We also were not following basketball rules: each time he makes a shot, it’s worth 50 points. Each time I make a shot, it’s worth 1 point. We were still playing basketball, weren’t we?

Also, he didn’t have to dribble: he could run with the ball as much as he likes. We were still playing basketball, weren’t we?

Lastly, we were not even using a basketball ball. We were using a soccer ball (our basketball ball was too heavy for him). We were still playing basketball, weren’t we?  I believe so.

My point is that there is a core in Agile that represents the essence. The card wall is not an essential part of it.

The idea of the card wall originated from the concept of ‘kanban’, a Just-in-Time (JIT) system developed at Toyota many years ago (as far back as the 1930s would you believe it?).  I’ll write about what kanban is in another post, and explain the big difference between it and how the card wall is used in Agile development. 

The important thing is that in Agile, the card wall is simply a reporting tool.  It give you a synoptic (‘at a glance’) view of where things are.  It is not part of the essence of Agile.

The essence of Agile is constant feedback and constant adjustment. 

The card wall, the daily stand-ups, even the sprints, are merely communication and administrative techniques.  You can replace each one of these with completely new techniques (potentially better) and still be doing Agile!

A quote on failure

A great quote on failure and its implications:

 “My great concern is not whether you have failed, but whether you are content with your failure” – Abraham Lincoln

Everybody fails some time.  Olympic champions fail, the most brilliant scientists and engineers fail, the most astute and experienced businessmen, the most competent professionals, the greatest actors and actresses, everybody.

The only ones who don’t fail are those who don’t try. 

The great differentiator is what they (and we) do with failure.

Problem solving processes

Koberg & Bagnall, the authors of “The Universal Traveler”, propose a methodical problem solving process.  Their process closely resembles the systems approach to problem-solving, an example of which I’ll include below for comparison.

K&B’s process has seven stages:

1. Accept – accept the challenge of solving the problem (this is unique to K&B I think)
2. Analyse – familiarise yourself with the problem; understand its ins and outs
3. Define – determine the main issues; conceptualise and clarify the aims and goals
4. Ideate – generate possible solutions to the problem
5. Select – compare the alternative solutions and select the best one
6. Implement – take action to implement the solution
7. Evaluate – measure success; check how well the problem has been solved.  In addition, reflect on the experience and learn what you can from it for future applications.

To compare, here’s a typical approach for a ‘hard’ systems engineering approach, taken from Zust and Troxler’s “No More Muddling Through”:

1. Situation analysis – similar to the ‘Analyse’ section of K&B
2. Goal definition – define the parameters of what we want to achieve
3. Concept synthesis – development of alternative solutions.  Same as K&B’s ‘Ideate’
4. Concept analysis – analysis and evaluation of the generated alternative solutions.  Same as the first part of ‘Select’ in K&B
5. Evaluation – comparison of the alternatives (when none appear to be the obvious best choice)
6. Decision – selection of the solution

The most obvious difference is that K&B’s covers more ground: it treats acceptance of the problem as part of the process.  At the other end, it adds two stages: Implement, and Evaluate.

Come to think of it, if you only select a solution and not yet implemented it, you have not yet begun to resolve the problem.  It’s therefore hard to think of Zust and Troxler’s ‘Problem-Solving Cycle’ as a complete problem solving process (it’s still an excellent book and one of my favourites for systems engineering).

 

del.icio.us Tags: Problem Solving Process,The Universal Traveler,Systems Engineering

Creativity is not normal

I am currently absorbing a book called “The Universal Traveler”, a book on creativity and problem solving using a (soft) systems approach.

The authors suggest that by definition, creativity is innovation, which is about coming up with something new.  Something new is something not normal but different.

“If you accept the fact that the goal of creativity is innovation, you should realize that creating something “new” is NOT NORMAL but DIFFERENT from normal, perhaps even ‘abnormal.”

Think about it. If people are immediately accepting of your ideas or your behaviour, then perhaps your ideas are not really that unique.

“If you believe you are behaving creatively and your behavior is readily accepted in normal society, one of two conditions is probable: either you have conditioned society to accept your abnormal actions or your input is really not as unique as it seems.”

You may come up with innovative ways of attacking a problem.  But is it really innovative, or is it just an idea already applied elsewhere (perhaps even by yourself).

Underwater weddings, wedding on rollercoasters, getting married while parachuting are all variations on a unique idea.  Whoever first thought of getting married differently from the norm gets the credit for creativity.  The rest are just extensions of the same basic idea; they are not innovations.

What is the point of creativity though?  Creativity for its own sake may be important for art, but where else?  For businesses certainly, it becomes important as a differentiator: new products and services. 

The iPhone is innovative. All the other look-alike smartphones are variations.  As we can see, innovation by itself does not guarantee commercial success.  While the iPhone may be the leading smartphone, the Samsungs and others are enjoying tremendous profits as well.

But to me the most important application of creativity is for meeting the challenges of new problems.

New problems, by definition, do not have a history of solutions that have been successfully applied against them (that would mean they are old problems, not new).   New problems require new solutions, something that have not been tried before.

And that is where creativity comes in: in the generation of new ideas.

Using PERT in MS Project 2010, Part 1

I want to investigate and write about how to use PERT effectively in MS Project.  But first I’ll do a review of the basics of PERT.

PERT was first developed within the United States Navy’s Polaris submarine program as a tool to help manage that very large, very complex, and unprecedented undertaking. 

The term stands for Program Evaluation Review Technique.  The focus of this management tool is on evaluating and forecasting the likely duration of a project.

Its distinguishing characteristic is recognising that project tasks are not deterministic: you cannot say with absolute confidence that task A will finish in 3 days, task B will finish in 5 days and so on. 

The reality is that task A might finish in 2 days if everything goes well, might finish in 3-4 days in most circumstances, but can potentially take 8 days if some problems arise.  So any project schedule crafted on the basis that A will take 3 days and B will take 5 days is simplistic, and is not based on reality.

To properly use PERT, you need to provide 3 duration estimates for each task in your network of activities:

1. The optimistic duration (T_Optimistic)
2. The most likely duration (T_{Most Likely})
3. The pessimistic duration (T_Pessimistic)

The optimistic duration is our estimate of how long a task will take if everything goes well.  If we have previous experience of finishing a similar task where everything went according to plan, we can use that historical basis for our estimate.

The most likely duration is our estimate of how long the task normally takes, given the normal disruptions of normal execution.

The pessimistic duration is our estimate of how long the task will take to complete if things just are not working out.  We can also use historical data if available. We’ll need to put an upper bound on this estimate because clearly there is no limit to the kinds of things that can go wrong, and we cannot include all of them in the estimate.  If the task was painting the exterior of a house, we might consider such things as the impact of rain suspending the work, or of one worker calling in sick, or even running out of paint and the accompanying delays of buying more paint. 

Once we have gathered the 3 durations, we use the following formula to come up with the most likely duration of the task:

T_Likely = (T_Optimistic + (4 * T_{Most Likely}) + T_Pessimistic) / 6

Example:

TOptimistic	20 days
TMost Likely	25 days
TPessimistic	35 days

Then

T_Likely = (20 + (4 * 25) + 35) / 6 = 25.83 days

And we will use 25.83 days as our estimate for this task. 

We perform the above procedure for each task in the project network,  computing the T_Likely duration for each.

Systems Engineering–Coping with Complexity

A readable introduction to Systems Engineering. 

 

Listed below are some of the books referenced by the above work.  This list is not necessarily complete (Sometimes, I list only those that interest me).  When there is a newer edition of a book than the one originally referenced, the link is to the newer version.  Items marked with a , are works I can recommend.

Title	Author	Remarks
Winning at New Products	Robert G Cooper	Amazon
Metrics and Case Studies for Evaluating Engineering Designs	William L. Chapman, F. David Van Voorhees, A. Terry Bahill, Jay Alan Moody	Amazon
The Anatomy of Major Projects	Peter Morris	Amazon
Systems Thinking, Systems Practice	Peter Checkland	Amazon
Turn Signals are the Facial Expressions of Automobiles	Donald Norman	Amazon
21sr Century Jet – The Making of the Boeing 777	Karl Sabbagh	Amazon
The Sources of Innovation	Eric Von Hippel	Amazon
Object-Oriented Software Engineering: A Use Case Driven Approach	Ivar Jacobson	Amazon
Principles of Software Engineering Management	Tom Gilb	Amazon
UML Distilled: Applying the Standard Object Modeling Language	Martin Fowler, Kendall Scott	Amazon
Real Time Structured Methods	Keith Edwards	Amazon
Object-Oriented Modeling and Design	James Rumbaugh	Amazon
Notes on the Synthesis of Form	Christopher Alexander	Amazon
The Rise and Fall of Strategic Planning	Henry Mintzberg	Amazon
Normal Accidents: Living with High Risk Technologies	Charles Perrow	Amazon
MANPRINT – An Approach to System Integration	Booher	Amazon
Value Analysis and Value Engineering	Frederick Oughton	Amazon
Invention by Design: How Engineers Get From Thought to Thing	Henry Petroski	Amazon
The House of Quality	J. Hauser, D. Clausing	Amazon
To Engineer is Human	Henry Petroski	Amazon
Product Development Performance	Clark	Amazon
Design Methods	Christopher-Jones	Amazon
Software Inspection	Tom Gilb, Dorothy Graham	Amazon
The New Rational Manager	Kepner	Amazon
Against the Gods: The Remarkable Story of Risk	Peter Bernstein	Amazon
The Sciences of the Artificial	Herbert Simon	Amazon
Managerial Economics	Evan Douglas	Amazon
Mastering the Dynamics of Innovation	James Utterback	Amazon
The Product Manager’s Handbook	Linda Gorchels	Amazon
Intellectual Capital	Thomas Stewart	Amazon
New Products: The Key Factors in Success	Elko Kleinschmidt	Amazon
Systems Engineering Guidebook: A Process for Developing Systems and Products	James N. Martin	Amazon
A Quantitative Approach to Software Management	Kevin Pulford	Amazon
Skunk Works	Ben Rich	Amazon
The New Organizational Wealth	Svieby	Amazon
Peopleware: Productive Projects and Teams	Tom DeMarco, Tim Lister	Amazon
A Methodology for Systems Engineering	A. D. Hall	Amazon This is a classic.
The Fifth Discipline: The Art and Practice of the Learning Organization	Peter Senge	Amazon
Guns, Gems and Steel: The Fate of Human Society	Jared Diamond	Amazon
The Blind Watchmaker	Richard Dawkins	Amazon