Leading the way.....

Just reading this book for the second time:His Excellency: George Washington what an amazing person - talk about putting it all on the line for something you believe in. He may not have been an exceptionally great general, but what he DEMONSTRATED in all of his actions was well beyond those around him. Just inspirational. Dedication, determination, endurance and outstanding morals. When in doubt of what to do, it's examples like this that help make the decision much easier.

Rules of Engagement

Big project, multiple teams, external vendors, multi-dimensional deliverables, MANY user groups, to many sponsors, lots of technology. The first step in the process is what I call Meta-Planning - aka Planning to Plan. What tools will you use, how will you communicate, arbitrate (aka manage the finger pointing), etc. You want to establish protocols and communications channels in order to reduce the overhead costs and exponential risks based on the various complexities. The same principals apply to large projects as they do with small ones, but more so. The biggest issues you will have is in cooperation and communication - resource issues. You will be working with teams with conflicting interests, various levels of engagement and varying skill sets. Some base items to establish:

• Players list - who's on what team and what is their role, how do you contact them, who is their backup and who do they report into (org charts are great)
• What planning tools to use? MS Project (hopefully you have something better)? Standardize the structure, terminology, information to be captured. Utilize milestones from the various teams (no one can track the meaning of 100,000 tasks, but 100 milestones is manageable)
• Create a terminology dictionary - is blue - blue?
• Ensure consistent definitions - what is a completed tasks? focus on the quality aspects and the hard delivery (task 23 - function X delivered to beta group with no severity 1 or 2 errors)
• BE TRANSPARENT - the more you hide the more they hide the more no one knows anything.
• Tool sets - ensure that a task in the plan is the same task in the bug tracker is the same task in the documentation - consistent cross tool level of definition.
• Understand each teams deliverables - IN DETAIL.
• Create a communication plan - who gets communicated on what - subscription (weekly updates), events (task W is being delayed), change management (the users would prefer blue to red), etc.

There's many more items to review - but the same approach taken to deliver the project should be used to create the approach to the plan. PM the planning, create a scope, requirements doc, communication plan, change management - for the planning. Project Management is a overhead cost to the project - it does not delivery a product it reduces risk - make sure you effectively manage the management or the costs will be as great as the 'official' project an increase risks instead of reducing them.

Beware of NUMBERS!

When numbers are discussed and more importantly when they are presented in a document, there is a feeling that they accurately represent the truth: 212,323 unique visitors came to your site this week and of those 15,932 became active leads. Seems real, especially when you include the precision of 212,323. Unfortunately many (most) people don't questions how accurate the numbers are, what could be impacting them one direction or another and what the real meaning is. GEE - with those numbers we should be millionaires within a day or two - time to order more product from the factory so we don't get behind on delivery - right? There should be some WAY to provide numbers that reflect reality and the comfort level of them - for instance, what if the number provided was 90% accurate, could we represent it in a color like 212,323 or less accurate like 212,323?? or provide a less precise number as the quality of it declines: 212,300 to 212,000 to 200,000+ ?? If we provide the % deviation at the bottom of the page (the numbers above are within 50% of reality) are we misleading the people reading the information? Ed Tufte questioned extensively the info provided in Power Point Presentations. I think we need to question how we present data in general and make sure we're not misleading people based on the numbers provided. We should also include what could be impacting the #'s - for example - now many of those unique visitors are actually Google search bots scanning the site for indexing? or how many are links to pictures on your site from MySpace users? Not real unique users in the sense that they'll become potential leads - right?

Not much you can't do.......

Just finished watching Cast a Giant Shadow for the 20th time - the story of the birth of Israel, Mickey Marcus and the Road to Jerusalem. Being Jewish, perhaps it meant a bit more to me then it would to most. IT DOES reinforce the believe that I have that There's not Much You Can't Do. When confronted with a problem (barrier):

• make sure you understand what it is - don't focus on the symptom and not the problem. What is it that you're trying to resolve, accomplish, etc. - remove the noise from the system ASAP.
  
• realize that the most limiting factor in coming up with the solution is usually YOU - preconceived limitation, to narrow of a focus, to deep in the weeds....start with the approach that nothing is not possible - there are no inherit limitations in developing the solution
  
• keep it simple - overly complex solutions often add to the problem instead of resolving it
• keep the focus - don't get distracted
• be positive - there are always reasons not to do something, always potential for failure - move forward bravely
• keep things in perspective - MOST OF US are not dealing with life critical issues...MOST OF US are not catching babies falling from the sky (but some of us are - not me - but some of us)
  

Could have been a doctor........

I remember once hearing Iron Mike say that, if he had focused on it, he could have been a doctor. There could be a lot of discussion around Iron Mike and what could have been - but a doctor, I think, would have been a bit out of his range of achievements. Who am I to talk?? Someone that has recently been humbled. With about 20+ years in IT - managing teams - projects - etc. - I began to think that I could do a lot of things, putting a simple marketing presentation together being one of them. Well to my surprise, what I put together was more like a IT presentation, focusing on the typical presentation hot points of why us, look what we've accomplished and hear what we can do......but at the end of the day it was an IT focused presentation for a marketing group. It took about 30 minutes of a real marketing person's time to put a real marketing presentation together - one that made me say WOW!

This above all else: To thine own self be true.
And it must follow, as the night the day,
Thou canst not then be false to any man.

William Shakespeare

What tail is wagging the "user happiness" dog? - link to post by Kathy Sierra

A MUST READ FOR EVERY ONE IN IT!
http://headrush.typepad.com/creating_passionate_users/2007/02/what_tail_is_wa.html

Happy St Patrick's Day!

Have a Happy St. Pat's Day - Lift a cold green beer and rejoice!
(put your sound on)

Visualize Success

In order to be successful, you need to visualize what success is. We are so driven to do things and make improvements and develop road maps of change, etc. that we often lose sight of where we are going. Many times as we try to create a road map, we limit ourselves based on past experiences, imagined barriers and preconceived notions. Yes - we are our own greatest limiting force. When I start to work on a new proposal, the first thing I do is try to imagine what success looks like, without any limitations.

Now I'm not one to be real touchy-feely about things or to evangelize a happy place, but I do know that there is not much that can't be done. By having a solid vision of success without limiting factors provides us with an end point - the fun starts as we try to develop a plan to get us there. It's amazing how much can be done and how many barriers could come down if we truly understand success and are able to communicate it to others. As Grandpa use to say 'the toughest part about getting a job done is starting it'. Next time you get a chance to work on a new plan - start with the vision of a very successful conclusion and then build the plan to get there.

Interesting links to the Agile community

Thought I share some interesting background via links to the Agile community, where it came from, etc.:

Martin Fowler reivew of the 'Meeting'
http://www.martinfowler.com/articles/agileStory.html

A review of the founding meeting in Dr Dobbs:
http://www.ddj.com/showArticle.jhtml?articleID=184414755

Principles behind the Agile Manifesto

History: The Agile Manifesto

and of course
http://www.agilealliance.org/

Just some interesting reading, if you have the time.

Back to the basics

A lesson I learned long ago in another area: when in doubt, go back to the basics:

Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

The Apprentice

First time, I've seen The Donald's show 'The Apprentice' and I guess a combination of low expectations, beer and pizza helped in seeing it as something more then awful. The show had two teams each having to create a half time show at a soccer game for GNC. The 'losing' team basically had a bad idea badly implemented. So, at the end of the show, the PM was 'fired', not the person who came up wit h the bad idea or anyone in the team who helped implement the bad idea or the person who spent the show hedging his bets and covering his butt. Lesson 1: the show is like reality, project managers are not judged on how they manage but how successful the team is - IN MOST COMPANIES and politics plays a substantial role in determining who 'takes the fall'. Unlike what is taught in Project Management 101 (where the focus is on PMBOK) - that a PM is judged by how they follow the PM processes and manage, real life is a bit different. A PM needs to: know how mature the company is that they are working for and adjust their plan to

1. know how mature the company is that they are working for
   
2. realize that they need to ensure they continue to have a job, in order to have the opportunity to help mature the company (if possible)
3. realize how they will be judged
4. know who's in and who's out and adjust as well as possible
   

Be careful, selling your soul for a job in a company is in all cases not worth it - but sometimes you need to play the game in order to change it's direction (Aikido like).

Here's a link to the specific show: http://apprentice.tv.yahoo.com/trump/06/episodes/week8_videos.html#1643682
And the PM who got the message You're Fired! (from the Donald)
http://apprentice.tv.yahoo.com/trump/06/candidates/surya_bio.html

Think Small

Great article: http://sloanreview.mit.edu/wsj/insight/innovation/2007/03/03/
Found while reading the WSJ which I find VERY INTERESTING (not sure why)

Know your data

One of the biggest 'issues' I see with developers is that they attack issues without clearly understanding the problem or data area that they are dealing with. I think it was Yourdon, Weinberg or one of those guys from the old school of programming that said 'resist the urge to code'...and Agile that pushes test driven development (TDD) - either way I think the idea of understanding the problem being addressed is one item to review the other is the data area - aka information. If someone presented a problem of 'provide a report of activity over the last 12 months based on searches by users who entered a specific ID - the ID is a text field' a developer might go off an start developing a generic approach that would potentially account for billions of rows of activity against some large non-repeatable text ID. What if the ID was a list of US states? and the potential range of user activity was 2 to 10 a month? How would the solution differ? The first would potentially be a super computer driven application estimated at 100 person years of work and the one where the data is understood, perhaps a simple spreadsheet that would take 20 person minutes.

Do Project Managers suffer the same way? Off inserting tasks into MS Project prior to understanding the problem and data area? All the time. And the excuses given are typically the same:

• there's no time to think, they need an estimate today (one that will be way off and either put the user into sticker shock or lose the PM their job because the project went over the budget by 10,000%)
• over complicating the matter 'gee - they said they needed to count to 10, the person could be speaking in any language, or it could be a plant that needs to count to 10 and perhaps the plant has no leaves to count on...'
• over simplification - 'all they want to do is go to the moon - I can see it from by back deck, how hard could it be - point and shoot the rocket thingy'
• 'we need to develop a plan for a web site where people could enter their lunch order - let's see McDonalds servers over 10 million people so......' (and the local pizza place gets an estimate of $1,000,000 for a simple web site).
  

Support Leo!

http://www.twit.tv/
Great site for tech podcasts!

Probability

I'm 30% sure that 80% of the work will be completed within 5% variance of the estimated completion date. What? Just finished reading an article about using probability calculations (Monte Carlo) to determine when tasks will be completed. This provides the percentage of certainty of when tasks will be complete. The example provided consisted of 2 tasks each with an estimate of 8 hours and it was determined that there is a 50% chance of them being completed within the 8 hour estimate (each) or potentially 80% chance of being complete with in 16 hours (each) - aka 'it took you twice as long to complete??? why??'. Where I think this type of discussion interesting - I find the approach useless. Realizing that a small project could consist of 30-50 base tasks, many relying on prior tasks completions/output to begin, etc. - the ability to use probability to determine the resulting bell curve to determine percentages of completion based on time, etc.....is slim based on typical system noise (chaos theory 101). Maybe if I went to MIT for Probability type classes (math) - I might have more faith in utilizing it for estimating and realizing the value (http://ocw.mit.edu/OcwWeb/Mathematics/index.htm?gclid=COzStYCO4IoCFQk_gQodMxTAxw).

In addition to dependency on related tasks one also needs to consider:

• quality of delivered product (poor delivery results in additional future work, etc.)
• quality of resources
• definition of complete
• external factors (chaos)
• overwork (over delivery - fish getting as big as the tank)
• communication ('oh, by the way task x was complete a week ago - sorry about that')
• vacation, sick time, to much beer, general distractions (planned and otherwise)

How probable is the probability usage accurate enough for use? If at best you can get within +/- 100% (example from article) - I think dart throwing (currently the most used method in estimation) is just as good. In other words, what is the cost of using probability to provide estimates where the current process is relatively the same. If you want better estimates and better results take the $ and spend it on better resources.

Encapsulation

Encapsulation? for Project Management? Encapsulation is defined (at least in regards to Object Oriented programming) as Conceals the exact details of how a particular class works from objects that use its code or send messages to it.
So what does this have to do with PM? How often is a task defined that either is not complete OR does not sufficiently hide minute details to reduce confusion/complexity. For instance: Task 121: Install Web Server in Production - you would assume (ASS-U-ME) that this is the complete installation of a server, unless otherwise defined. But in many cases it refers to the simple connecting of a server to a network, i.e. network and power cable - and not the configuration, testing, etc. that is also required for a complete installation of a server. To the other extreme the installation task could have 20-30 sub tasks painfully explaining every detail. (take server out of box, without dropping place on shelf, look lovingly at server for 5 minutes, etc.). To reduce planning complexity, ensure complete/whole-product delivery, etc. I THINK the simple definition of encapsulation in the PM documents would help set expectations as what a task is, etc. and put in place the understanding of the level of detail required to track. Report at the detail level required based on risk factors, Encapsulation as much as possible to ensure reduced complexity which enhances clear communication.