Ed Yourdon

I recently attended the IT Metrics - Software Best Practices Conference in Princeton, NJ. Ed Yourdon gave a presentation on the Top Ten Best Practices. Great information and great approach (mind mapping). The best part about it was the Top Ten list have been around since the 1980's and Ed Yourdon was just reiterating the need to apply the basics to be successful. Great conference - humbling experience. BACK TO THE BASICS!

5 Steps to Project Success

http://www.hyperthot.com/pm_wbs.htm

Genius!

Raising Expectations

Re-reading Managing the Absurd by Richard Farson recently and ran into the Theory of Rising Expectations:
'Revolutions are most likely to occur when a prolonged period of objective economic and social development is followed by a short period of sharp reversal...' - James C. Davies (http://en.wikipedia.org/wiki/James_C._Davies)

In terms of projects: If the project is proceeding very well and exceeding expectations - then runs into an 'issue', is the reaction from client, team, etc. more dramatic then if the project was proceeding as planned or not meeting expectations and then ran into an 'issue'...??? Makes one want to rethink how we communicate how successful a project is proceeding ('Gee, you told me last week we're ahead of schedule by a month and now you're telling me we're only ahead by 3 weeks....think we have to replace the project manager...') - something to think about.

The Standish Group - CHAOS Report

A must read - the report is over 10 years old, but the findings, approach and underlying information is still valid (which shows how little progress has been made in ten years):
http://www.standishgroup.com/sample_research/chaos_1994_1.php

And the follow up - Unfinished Voyages:
http://www.standishgroup.com/sample_research/unfinished_voyages_1.php

From the Report - success scale - performing this exercise itself would most likely improve your project's probability of success

SUCCESS CRITERIA	POINTS
1. User Involvement	19
2. Executive Management Support	16
3. Clear Statement of Requirements	15
4. Proper Planning	11
5. Realistic Expectations	10
6. Smaller Project Milestones	9
7. Competent Staff	8
8. Ownership	6
9. Clear Vision & Objectives	3
10. Hard-Working, Focused Staff	3
TOTAL	100

Culture and Project Management

Recently reading up on corporate culture and was wondering what impact it has on project management. Culture is divided into three groups:

• Cooperative - everyone works together in a productive manner
• Aggressive - power play and positioning
• Passive/Defensive - CYA - don't do more then you're title calls for, etc.

Based on these divisions, it would make sense to adjust the project management approach accommodate each of the culture's needs. Obviously, few companies fit completely into any one of the divisions and could have conflicting sub-cultures. Taking all of that into account, it would make sense to understand the culture you are working with and fine tune your approach accordingly (do we do this subconsciously now??) - for instance:
Passive/Defensive - make sure you have clearly defined deliverables and who has the responsibility for it. Ensure they are consistently reminded of their assigned tasks and reinforce by naming names. Is there one culture more productive then another? Perhaps, but perhaps it's a matter of understanding the culture and working it in the way required to get the results you need. A Passive/Defensive culture, if understood and plans adjusted accordingly, could outperform a Cooperative one - for instance a Cooperative culture might stray from the project's desired results in order to provide a more creative (and more costly) approach as opposed to one that is truly needed or required (gee - you built a great bio-feedback brain connected data capture device - however all we needed was a keyboard connected to the computer).

The bigger the plan the less the value

'In preparing for battle, I have always found that plans are useless but planning is indispensable.' - Dwight D. Eisenhower

In some cases plans are worse the useless, they become a detriment to the project - they become a risk to completing the project on time, on budget and with the expected quality.

Planning is a method of:

• uncovering tasks required to complete a project
• identifying risks
• identifying level and types of required resources
• uncovers potential conflicts with other projects
• communicating to users, team members and sponsors
• the potential timing of deliverables

Once a plan is 'put to paper' (printed, communicated out, saved) it has become obsolete, most likely due to delivery dates needing to be updated for 100's of various reasons. The more information in the plan - the more effort (cost) is consumed in maintaining it and communicating out, not only for the project team, but also for those the project team need to work with in order to help update the plan (developers, users, etc.). This is similar to analysis paralysis - planning paralysis - where the majority of time in a project is spent on maintaining the plan instead of completing the work to delivery the planed objectives. One indicator of this could be the effort associated with project meetings compared to actual work effort. I would take a rough guess and say that if time/cost associated with project planning/maintenance exceeds 10% of the entire project budget then the project management has moved from reducing risk to being a risk. This does not include time required to meet required reporting (SOX compliance for example).

Take a close look at the 10,000 tasks MS Project plan you've just printed out and think about the time (cost) associated with maintaining it - could you gain more benefit from a less detailed plan? Did the project team lose sight of the project planning benefits? (risk reduction through identification of required work, risks, etc.)? Make sure that the project plan is not an anchor instead of a guide.

Herding the Ox

Here's another great example of the Zen 'Searching for the Ox' metaphor: http://www.emoyeni-retreat.com/id99.htm
I think one of the unspoken teachings is 'be careful of the ox you seek for you will become it and it will become you'.

Re-Estimating

Still in the process of reading Software Estimate by Steve McConnell and I'm still very impressed with the book. One idea in the book is that, as your project proceeds you need to continually re-estimate - you start with a range, over the course of the project the range of delivery time/effort/cost gets more precise and you really know the true effort once the project is complete. I'm in totally agreement with this - HOWEVER - how the hell do you provide a proposal for a project to a client with a range? Internally it's difficult (gee, it could take anywhere from 4-24 months and 2-5 resources to complete)....but when you work with external clients - how do you help them understand and accept? If you provide a range they'll need to know an exact amount (precise but not accurate) so they can plan their budgets - and it would be a very difficult thing to come back every month with a new estimate that could be +/- 200% or more. 'Gee Sue - project X could cost $10,000 or $90,000 - I'll provide a monthly re-estimation until we're done.....'.....

I'm in complete agreement that this is reality - you don't know how long something will take until it's complete (and don't forget the quality factor) - but how can you utilize the estimation techniques to provide a good-enough estimate, one that will not lose you money on the project and one that is not high-above all of your competitors. I guess that's the million dollar question.

Pick your environment

The book I'm currently reading - Software Estimation - comments on the fact that interpretive languages tend to allow programmers to be more productive then compiled - php vs. C# for instance. True??? In my time of writing code, I've found it to be true. You can relax some standards, get quicker feedback and focus on problem solving instead of code creation tasks. I'm sure this will upset many people (or in reality those few who will read this), but that's my gut reaction to the comment in the book. I know there are many arguments regarding whey compiled languages and more rigid development environments produced better quality, more reusable code, etc...but I think both are arguments that need to be substantiated with quantitative research. The simple measurement should be business value. What tools (languages, IDE's, base platforms) provide for the best ratio of benefit to costs, both short and long term. Will we find that interpretive type of environments lend themselves more to short term benefits and more rigid one's to long term benefits? Perhaps....

Metrics

The value of metrics in in the value of the answers that they provide to our questions. To ensure the most value is provided, we need to ensure that the most valued questions are being asked. Historically, metrics have been gathered to determine how systems have performed and how the systems compare to competitive systems. The higher level value is in asking where should the systems be directed and how can we ensure the highest life time value (LV) is obtained from our customers.

Software Estimation - great book!

Software Estimation: Demystifying the Black Art
by Steve McConnell

I'm about 1/3 of the way through the book and it's A GREAT BOOK and GOOD READ. The discussion on Over Estimating vs. Under Estimating is worth the $ and the time in itself. What are the cost, risk and overall project benefits between underestimating a project compared to overestimating? Steve M. gets into it - you may agree or not agree, but the reasoning, historic data, research, etc. provides a lot to think about. Without a good estimate, project justification, planning, etc. has no legs to stand on. Tired of throwing the dice/spinning the wheel in getting an estimate? I think this book provides more common sense guidance then I've read in a long time.