Sorry, couldn't resist.

A well known and very vocal Project Management instructor made a statement about Government Projects always being late and over budget. Then making a not so subtle suggestion that his competency based assessment approach, versus the PMI approach to certification, is solution to better project management.

Man, do I wish that was the case. Here's my hands on experience in the government (DoD, DOE, DHS) experience on the program controls side.

• Requirements changes impact programs in ways that are not desernable when first suggested. We see this all the time. "Let's make this change from one real-time control data bus to another real-time control bus for all the right reasons" - faster, better, cheaper. But then the second and third order impacts start showing up months later.
• Techncial architecture impacts are many times unknown. "Let's scale up the number of processing units from 20 to 100. It's only a 5 times increase, so let's up the cost and other impacts by 7 to account for unknowns. Turns out the real impact was not 7 but 14, twice what was estimated. Materials impacts, process flow impacts, the overall thermal impacts were huge impacts on the program.

The  processes used to manage a program are absolutely necessary for success. Earned Value Management, prorgammatic and techncial risk management, Systems Engineering, Measures of Effectiveness and Measures of Performance driving the Techncial Perfomance Measures.

But necessary of OK, what about the sufficient conditions?

• Senior management must behave in rational ways.
• Change control is mandatory, not as a "constraint," but as a process to reveal impacts
• All parts are connected, no matter what the suppliers say. A Systems Engineering paradigm is mandator for all things other then simple projects.

These, and many others, are not directly related to project management processes, even the general purpose ones found in PMBOK®.

At the bottom of this discussion the "necessary AND sufficient" conditions starts and ends with:

• Past performance,
• Extensive experience,
• Processes and tools, and
• The necessary leadership to put all this together.

Now how can we increase the probability of project success? This is the 64 thousand, 64 Million, and maybe 64 Billion dollar question.

Simple, and many times simpilistic soultions are just that simple and many times simplisitic.

We have to remember ...

For every complex problem there is an answer that is clear, simple, and wrong. - H. L. Mencken

There are no soltions to complex problems. Complexs are part of our current life paradigm. All the easy problems have been solved. So rarely will there be a problem that can be solved with a simple solution.

I recently came across the Top 15 Worst Logo FAILS ever. It lists a number of logo designs that, in all their innocence, invite all kinds of associations with some not so innocent human behaviors. I laughed so hard that part of my brain was dangling from my nose. I suppose it is proof of my wicked mind that I immediately recognized the problems in all logos.

Unfortunately, a lot less funny was someone’s comment that my six-eyed monster, which I designed as an illustration for my upcoming book, looks suspiciously phallic in nature. Despite having a wicked mind, I had never noticed this myself. But now that the association has been mentioned, I am unable to get it out of my brain. I just cannot laugh hard enough about it.

At a recent Agile Holland event two other flawed designs were presented and discussed with the audience. One of them was RUP, and the other was PRINCE2.

The RUP model is flawed because it invites associations with the waterfall process.

The design (I apologize for the unsharp photo) clearly suggests that the RUP process starts with n iterations of specification. And there are no frequent releases in this model, because a release into production (as suggested by this model) only happens in the last phase, after everything else is finished.

The PRINCE2 model is flawed because it invites associations with Big Upfront Process Design.

The model depicts lots of process boxes, and they all have arrows leaving and entering them. (Note: the picture I took here is the simplified version.) Such a design makes it hard for people to see that they are allowed to pick and choose their own elements from PRINCE2, because if they do they end up with many arrows dangling from boxes that go nowhere.

Now, don’t get me wrong. The intentions of the creators of all these models were good. The Arlington Pediatric Center never intended to be a seen as a pedophilic center. Martie the Management Model never hoped to be seen as a male, six times over. And the RUP and PRINCE2 designers never wanted to suggest that you should create a big waterfall-like process upfront.

All models are wrong. Some are useful.
And some are just badly drawn.

As the designer of a logo, illustration, or process model, it is hard (if not impossible) to predict what people will recognize in your designs. You cannot easily peek into the devious and twisted minds of your viewers. It is easiest just to show them what you’ve designed. Let them have a good laugh. And then try again.

As I will.

Jurgen is an experienced author, trainer, and speaker. Why don’t you hire him to add some spice to your company event or seminar?

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
If You Want Something Done, Practice Your Patience
About Project Success and Failure
I Follow My Rules, You Follow Yours

Project Management means different things to different people. From the social and humanistic aspects of managing the people working on and around projects, to the gritty details of a Performance Measurement Baseline, with in integrated cost, schedule, risk, and technical performance measures.

One advantage of working the in Space and Defense business is the social and personality aspects are minimized. Not gone all together, but certainly much less than commercial domains, where egos get in the way many times of getting things done. In A&D "done" is clear and concise - the machine flys away, the product does it's job as defined in the SOW, with measurable outcomes, soldiers are using the product, things like that. Black and White, either it flys or it doesn't fly. Of course it's not that simple, it never is.

But one thing that is different in A&D is the focus on the processes and tools. I'm working a moderate ($300M) Army program through January when we get to the Integrated Baseline Review (IBR). While poking around looking for some ideas for training our customer, I came across PM Lotus's "Setting Baselines in Microsoft Project."

The Baseline is just what it says it is, the "baseline" of the cost, schedule, and technical performance. Now MSFT Project is not the best at managing baselines. In fact it's pretty poor at managing baselines. No change control, no traceability, not much in the way of mandated documentation. But it's popular and most of our programs use MSFT Project.

Drill down into this site, there are some very good articles for those interested in the programmatic aspects of project management. Like Checklists.

One of the most common anti-patterns I've seen in waterfall projects is the "90% done syndrome". It goes like this: the project will get quite quickly to 90% readiness and will look to be on time until that point. However, after the 90% readiness point is achieved we start to see more and more delays and blast through deadlines like there was no tomorrow.

Why is that? I've spent some time thinking about this question. With Agile projects we avoid this syndrome quite effectively by managing the scope. In practice we avoid the "90% syndrome" by declining to work on the content that would delay the project but not add enough value to justify that delay. But, then some time ago the question came back to me. Why is it that in waterfall projects we have the "90% syndrome"?

The answer to that question just hit me today (a real "d'oh" moment): the reason is that we don't really know about all of the requirements until we are well into the implementation (say 70-90% into it). Therefore we will only really understand the full content of the project when we are close to the end. This, coupled with the fact that waterfall projects tend to be organized architecturally/horizontally (instead of feature/vertical sliced) leads to knowing about critical requirements too late(90% ready for a long time) and not being able to remove content (because we release the lower layers before the upper layers) to meet the schedule.

This anti-pattern is quite simple, but apparently it takes time to understand the forces at play, and most managers (including project managers) constantly miss this point...

Photo credit: striatic @ flickr

Some teams don’t do demos at the end of their iterations. Many of the teams who don’t do demos also have trouble finishing all the stories they committed to at the beginning of the iteration. They continue, iteration to iteration, not always finishing, not getting to releaseable at the end of the iteration. And, sometimes, these teams don’t do retrospectives because they are not done.

There’s significant value in a demo at the end of the iteration.

1. The demo shows the team what they have done and not done in the iteration.
2. The demo shows the product owner/customer what they have done and not done.
3. The demo acts a a milestone–the team has to stop what they are doing to show the demo. They can’t keep going without doing a demo.

If you’re not demoing at the end of an iteration, reconsider. Use the demo to get feedback, record your velocity, and see if you are done enough with this project for now, or if you really need to continue working off this backlog.

Tweet This Post

There are many discussions around what works and what doesn't work in the management of projects. Words like:

• Earned Value can't work for our problem. I've seen it fail, so it can't work.
• Agile is nonsense, it's not right for our domain.
• Requirements must emerge from the development of software, you can't possibly define what the system will do up front.
• I've taught 100's of project managers how to implement PMBOK® so I must be capable of managing real projects, no matter the domain.
• And endless other anecdotal examples of how a person with an opinion generalizes that opinion to the universe of problems.

Here's a suggestion. One that I've observed over the years. Those years having started in the late 70's when managing software development was an engineering role and having landed in the defense system program management world these days with formal probabilistic models of performance for billion $ programs.

Here's my suggestion. There are 5 IMMUTABLE principles of Project Management. These immutable principles keep coming up every time I hear someone speak about the problems they are having with a concept. The previous post was a trigger to restate these principles.

Five Immutable Principles

If you're going to successfully manage a project you must ask and answer these five questions. If you don't have credible answers for these five questions, do not proceed as a project manager. Stop, get the answers. Insist the stakeholder provide answers. Without credible answers, the project's probability of success is lowered. Possibly lowered to the point of assured failure.

The five immutable principles of project management are:

1. Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now.
2. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan.
3. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable.
4. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.
5. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.

In the absence of credible answers to these principles, you can come up with all kinds of reasons why things (methods, tools, processes) won't work. In fact you can come up with almost any reasons as to why projects fail.

Answering this principles in some credible manner doesn't assure success. But it goes a long way to improving the probability of success.

 

I’ve never heard a good cook say, “this recipe doesn’t work here.”

What if a cook follows a recipe to the letter, and it turns out that the result is not what the cook expected? Can he say that the recipe failed to “work”?

A recipe is just piece of text, nothing more. You cannot say “The recipe doesn’t work,” because the recipe doesn’t do any labor. The cook is the one who does all the work.

If the cook doesn’t get what he expected, my guess is that he’s just an inexperienced cook. Maybe he didn’t compensate for the bigger-than-average eggs that he used, or the hotter-than-average oven, or the low temperature in the kitchen, or the bland taste of the cheap spices he got from the supermarket.

“The recipe doesn’t work here” is probably just an excuse for “I didn’t work to understand how to adapt to local circumstances and make the recipe work.”

So…

What if someone says “this software method doesn’t work here”?

Jurgen is an experienced author, trainer, and speaker. Why don’t you hire him to add some spice to your company event or seminar?

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Choosing Authority Levels for Team Members
Your Project Will Suffer from Power Laws
I Follow My Rules, You Follow Yours

I came across (actually Pat Richards alerted me) to an article about how Earned Value is not applicable for Software Development project. This article was in a PMI IS SIG news letter. See Pat's post. You can retrieve the article by following the link on Pat's Blog.

Here's the core of the concept proffered by a PMI Special Interest Group on Information Systems.

It is very difficult to accurately and objectively measure the progress in designing and developing software.

My first response was "really?" The very essence of project management is to apply some measure of progress to plan. Simply showing up and putting in 40 hours a week is a measure of progress to plan for a Level of Effort task like watching the trains pass the crossing. (They used to have a job like that in the old Federal Republic of Germany when I was there in the mid 70's detoxing from a tour in Vietnam).

Also the very essence of Scrum - or most agile development processes - is to produce planned measurable outcomes from the work effort. All agile methods MANDATE the production of working software. How to define what software to "get working" varies by method, but Scrum connects the work efforts with the "requirements" through a Feature and Story list developed by the stakeholder.

Software projects also have the problem of iterative development approaches in which certain activities often must be revisited a number of times before they can even be considered completed.

Yes this is true. This is true of every project on the planet. It's part of life cycle of projects. From the extreme approaches of XP to DoD 5000.02's procurement cycle, incremental and iterative approaches are used.

This is not a "problem," it is a fact. Apply the appropriate method to deal with this.

And then the final stroke is "really bad project management"

Many of the activities in software development projects more difficult to measure accurately and objectively in order to compute the actual earned value of the work accomplishments. It is very difficult to accurately and objectively measure the progress in designing and developing software. Often the project manager must simply accept the developer’s word for how they are progressing rather than use an objective measurement. For example, when is developing a computer program 25% or 50% or 90% complete? We can measure the cost of the developer’s efforts but not the needed corresponding progress toward completion.

Please tell me this is not the approach being blamed for software project failures. Better yet please tell me that Earned Value cannot be applied to software development because of these types of projects.

Earned Value is successfully used in a variety of software domains - Enterprise ERP, defense and space system, which are all software intensive, embedded control systems.

Core Success Critieria for Earned Value and Software Development

• Define the outcomes of the work effort in some tangible way. Physical evidence is best. 100% working code (at least for the planned deliverable) is best of software. Tangible evidence for other things is just that - evidence that work produced the "thing" that was planned to be produced on or near the day (or week or month) it was planned to be produced for something close to the cost that was planned.
• Define the way progress is going to be measured. 0/100% of the work. Either it's do or it's not done. Other measures of progress can be 50/50 (half when you start, half when you show up with completed product), apportioned milestones. But NEVER EVER is progress measured by asking someone "how far along are you  on the software module you are working on?" The answer can NEVER EVER be "well, I've been working real hard and I think I'm making progress, so let's say I'm about half way there with half to go."
• Define the tangible evidence, the date the tangible evidence is expected, and the associated costs.
• With this you've got all you need to do EV on Software Projects. Ignore completely the suggestion in the IS-SIG article, that EV and SW Dev don't mix. It's done every day on billions of dollars of software development.

If you can't afford to mitigate the risk now, be absolutely sure you can afford to resolve the problem later when it happens.

- Introduction to Universal Risk Report, The Risk Management Research and Development Program, INCOSE Risk Management Working Group.

The Design, Development, and Support of High Performance Teams

from The Hunter and the Hunted, James B. Swartz

When you study companies that have bee very successful in the development of teams and compare them to companies that have floundered, you will find that the successful companies share four characteristics:

• Missioning and Contracting
• Structure
• Leadership
• Team Development

Missioning and Contracting

First and foremost the team must have measurable goals that are relevant to the strategy of the business. For example, in Motorola's case the teams were assigned goals such as reducing cycle times, reducing defects, and reducing costs - goals that are a subset of Motorola's overall mission.

There should be a clear understanding of the responsibilities and authority (what the team will do and what they won't do) on the part of management and the team.

Structure

The elements of structure are process, organization, and technology.

• Organization: team members should be located as close together as possible, considering the situation. They should have a clear reporting relationship with the business.
• Process: The team would be provided with training in decision making and problem solving.
• Technology: they should have the best tools available for the job.

Task Leadership

Good team leadership requires a broad range of leadership capabilities, including the ability to both direct and facilitate activities. The most effective leaders focus the team on the mission, while at the same time developing the team's ability to manage itself.

Team Development

Teams do not start as the self-managed level regardless of the experience of the members. Their development can be compared to the processes of parenting. In the early stages both teams and children need structure and direction. As they mature (Hersey and Blanchard define maturity as a combination of willingness and ability, or "will" and "skill"), teams can manage first to be able to assess maturity level. Depending on the maturity of the team, the flexible leader us able to provide direction and coaching in early stages of team development and provide participative and facilitative leadership in the later stages. The effective leader empowers a team in proportion to its maturity.

Motorola has defined development levels that establish the level of empowerment a team should heave as iot graduates through tje stages of development

- Julie Thrope

You can hire me as a speaker.

I have previously been invited to speak for GlobalCollect, ISDC, Sogeti, Level Up, Imtech, and several other interesting businesses. They hired me to add a bit of spark to their company events, or to enrich their business unit seminars.
 
 
 

Why would you hire me as a speaker?

1. It is easier to inspire an entire organization with one well-designed keynote session than with an extensively crafted memo;
2. It is cheaper to fire up self-development of employees, than it is to send them all on an expensive three-day course;
3. It is an effective way for managers to show that they care, by inviting an outsider to share his experiences with everyone.

What topics can I talk about?

You can make me talk about anything you want. But these are my favorite topics:

• Agile/Lean software development
• Scrum, XP, Kanban
• Management/Leadership
• Systems/complexity thinking
• Social media/social commerce
• My book: Management 3.0

However, if there’s a special message you want me to get across, I can do that for you. Just give me the raw materials and I’ll turn them into a great delivery. With pictures. And style. Maybe even a joke or two.
 

What do my talks look like?

I use hand-drawn illustrations, metaphors, humor, and plenty of “brain rules” to ensure the best delivery. You can see a list of my standard presentations here. And I also have several videos available.

People’s ratings for my talks are consistently high. At the Dutch Testing Conference 2010 93% of the audience rated my keynote session as good (and 61% said it was very good.) At NDC 2010 my sessions scored 95% “green.” And at Agile 2010 I scored an average rating of 4,4 (out of 5).
 

What does it cost to hire me?

Here’s the good part: until the end of the 2010, when my book Management 3.0 comes out, I have a special offer! There will be a 50% discount for everything that I do. The special offer only lasts until the release of the book, and my availability is limited. So the earlier you contact me, the higher the chance I can say yes!

Simply email me the date/time, location, topic, duration, type of audience, and any other relevant details, and I will give you a quote.

Why hire me, and not someone else?

Here is my positioning statement (based on Moore’s template):

For software development organizations
who look for ways to inspire their employees
I offer talks and discussions about agile topics
delivered in an informative and entertaining style.
Unlike sessions by other speakers and consultants
my deliveries have style, impact, and silly pictures.
 

Why hire me now, and not later?

Of course, you can contact me anytime, both now and later. But other authors have told me that, once the book is out, I will probably be overloaded with requests for seminars and conferences. And I will need to say ‘No’ more often than I can say ‘Yes.’

I look forward to that, but you probably don’t! That’s why it is smart to contact me now, while it is still possible for me to cope with demand. ;)

(Or send this page to your manager, and tell him/her to contact me.)

Hope to talk with you soon...

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
How to Make a Presentation (part 3)
How to Make a Presentation (part 2)
How to Make a Presentation (part 1)

Nowadays, I make it a practice to call them into consultation on any new work ... I observe that they are more willing to set about a piece of work on which their opinions have been asked and their advice followed. - Columellama, Roma Landlord, 100 A.D.

I have been delinquent for those of you who subscribe to my email newsletter. I have not published one since April. On the other hand, I just posted Park Projects You Can’t Staff, For Now. The next newsletter is scheduled for Thursday morning. In case you’re wondering, I post the most immediate past newsletter when I queue one up for sending. If you decide to subscribe, you can rest assured I will not bombard you with email!

Tweet This Post

While not a fan of the "popular speakers," this quote struck close to home...

Success is the result of good judgment; good judgment is a result of experience; experience is often the result of bad judgment. - Tony Robbins

In his book “Succeeding with Agile”, Mike Cohn present nine questions that you should ask for a current or proposed team. Questions should be asked iteratively… until you answer “yes” to each. Here are the questions:
* Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members?
* Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)?
* Does the structure maximize the amount of time that teams will remain together?
* Are component teams used only in limited and easily justifiable cases?
* Will you be able to feed most teams with two pizzas?
* Does the structure minimize the number of communication paths between teams?
* Does the structure encourage teams to communicate who wouldn’t otherwise do so?
* Does the design support a clear understanding of accountability?
* Did team members have input into the design of the team?

Besides the cultural bias (in Italy, one pizza will usually feed one person but it might be different in the USA…), you could use these questions for every project that you are currently running or plan to run.

Reference: “Succeeding with Agile”, Mike Cohn, Addison-Wesley, 262 pages, IBSN 978-0-321-57936-2

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

Ranging from posting like "math is too hard," to "let's let the requirements emerge," I always troubled by the lack of attention to the underlying - many times the deep underlying - principles of managing software development projects.

Back in March, Guerrilla Project Management had a wonderful post about the Standish Choas report. But more imporantly are the papers referenced in the post. Rarely and I mean rarely do I encounter commerical IT projects that have discussions around these topics.

Here is a list of software development related conferences and events that will take place in September and that have media partnerships with Methods & Tools:

* Mobile Application Stores, September 7 2010, Zurich, Switerland

* iqnite 2010 Schweiz, September 21 2010, Zurich, Switzerland

* Lean & Kanban 2010 Europe, September 23-24 2010, Antwerp, Belgium

* Software Testing Analysis & Review Conference, September 26—October 1 2010, San Diego, USA

* iPhone/iPad DevCon, September 27-29 2010, San Diego, USA

* iqnite Nordic, September 29-30 2010, Stockholm, Sweden

* iqnite United Kingdom, October 4 2010, London, UK

* Agile Eastern Europe, October 8-9, Kyiv, Ukraine

Find more software development conferences

We're working a paper on the integration of Agile software development process and ANSI/EAI-748-B Earned Value Management.

Came across Considerations for Using Agile in DoD Acquisition. Worth a read.

Everything important has been said before, by someone who did not discover it.

- Alfred North Whitehead, 1916 address to the British Association for the Advancement of Science