Wednesday, February 28, 2007

Side Benefits

What are side benefits? If you seen the move Flags of Our Fathers and/or Letters from Iwo Jima then you've seen side benefits in action! Clint Eastwood decided do create the Japanese version of the same battle - probably using a lot of the same special effects, actors, footage, etc....Whenever you perform a task, put a project plan together, work on budgets, code, etc. try to think of what side benefits could be obtained - whose additional value is a true benefit. For example - tracking how people search sites, utilize functionality, etc. for the benefit of creating requirements provides the primary benefit - requirements. What about the framework you capture the information in? Could that be used for future work? The user behavior - could that be used for other development efforts in your organization? What about the tools used to capture behavior - could they be used in other ways? We often are under pressure for time and delivery and often overlook what side benefits could be obtained from the work we perform.


First heard on @nite

Tuesday, February 27, 2007

Valid programming test?

Is FizzBuzz a valid programming test?? Take a read:
Absolutely! I haven't heard of this one before, but I often ask 'suspect' developers to code (even pseudo code) a simple bubble sort or explain a Quick Sort - basic programming understanding - at least you would think. I think most programmers are more hacks then hackers (just my opinion of course).

A lot of grey out there....

Riddle me this:
What's black and white and a whole lot of grey?

Answer: Communication!
When communicating we often make a base mistake of thinking that all involved in the communication share the same background, understanding, predispositions, etc. - isn't it a shame that we all don't think alike? Simple words/phrases like task, end of day, complete, YES, etc. are often misunderstood by some/all involved. A PM's main responsibility (at least for this posting) is effective communication and to ensure effective communication will occur a PM should perform some terminology defining tasks. These could include sending out a terminology document, consistently using the same words in the same way over an over (consistent over communication), immediately correcting miss-understandings and miss-communications, etc. Never underestimate the negative effects of poor communication, never assume a good base understanding of any term and never miss an opportunity to reinforce a clear definition. Keep your eyes/ears open for terminology issues - some signs could include:
  • heated discussions over trivial items (you said it would be complete today!)
  • various groups discussing projects (IT and Sales - what a mix)
  • acronyms being used to often
  • the painful look of confusion
Beware of the Tower of Babel in your group!

What is a Platform?

Good article/blog post:
Nothing like providing valid definitions - makes discussions much more useful!

Friday, February 23, 2007

Send me on my way....

Google vs. Microsoft

As many of you probably know by now Google is challenging Microsoft in MS's sweet spot of profits - MS Office. Goliath vs. Goliath. Some people might be hearing about web based spreadsheet and word processing for the first time, but this has been in existence for some time ( My first impression - 'this is the end of the beginning' - the move to Internet based services have been in effect for MANY years, now that a huge company is actively pushing fundamental office tools reflects the maturity of the market and the ultimate move to it. It'll be here and in place before most expect and, I'm imagining, an easier transformation then many would expect. Some interesting questions:
  • Did Google time this to correspond with MS's Vista and new office announcements (if you're going to change, why not make the big change)
  • What type of privacy will be in place AND how liable will Google be for any leaks?
  • Will MS move to the same approach and make the correct business move OR stay tied to an old technology milking it for as long as possible (end of the MS empire? - is this why Bill Gates is moving on?)
  • Will this make the 'Internet community' more active?

Monday, February 19, 2007

Project Normalization - 2nd Normal Form

In a prior post, I started to discuss project normalization - based on database normalization:
I think it's time to look at the second normal form, Second Normal Form described in WikiPedia is: Second normal form (2NF) is a normal form used in database normalization. A table that is in first normal form (1NF) must meet additional criteria if it is to qualify for second normal form. Specifically: a 1NF table is in 2NF if and only if none of its non-prime attributes are functionally dependent on a part (proper subset) of a candidate key. A non-prime attribute is one that does not belong to any candidate key.
What??? Basically it's stating that any tasks defined by the task group and name can not be repeated. So, Environment, Setup Production Server - can only appear once - makes sense. What if you have more then one production server??? then:
  1. Environment - Setup Production Server/Database
  2. Environment - Setup Production Server/Web Server 1
  3. Environment - Setup Production Server/Web Server 2
So far Project Normal Form 1 and 2 have to do with how information is presented in a plan, makes sense, since if the information is not clearly and consistently presented in a plan then the plan itself will lead to confusion. The other part of the second normal form is that the other task attributes (resources, start/end date, etc.) do not impact and are not dependent on the identifying elements - which makes sense, since regardless of who or when of the task the group and task itself should not be affected. So, Environment - Setup Production Server/Database does not change if Joe is performing it as opposed to Sue.

Great video on what Web 2.0 is

and a related article:

Sunday, February 18, 2007

Gettysburg Address vs. PowerPoint-Gettysburg Address

Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal.
Now we are engaged in a great civil war, testing whether that nation, or any nation, so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this.
But, in a larger sense, we can not dedicate—we can not consecrate—we can not hallow—this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us — that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion — that we here highly resolve that these dead shall not have died in vain — that this nation, under God, shall have a new birth of freedom — and that government of the people, by the people, for the people, shall not perish from the earth.
(thank you WikiPedia:

Now compare this to the PowerPoint version:

Thank goodness PowerPoint wasn't around back then.

Saturday, February 17, 2007

Project Variation

Just how different are projects that we work on? On why is it that each needs such significant management? If we abstract out enough, shouldn't all projects look the same? Think - Plan - Work - Cover you Butts for what wasn't done ....that represents most projects I've worked on. Let's focus on software development, since that's what I'm most familiar with - and see if we can isolate what makes one different from the next...each one has something that needs to be developed, some level of uncertainty, some user interface, so much data to store-manipulate-report on...if the underlying systems remain the same such as the OS, development environment, delivery system, level of documentation, sophistication of application, same group of users and same group of developers, etc. - what makes one, to a significant degree, different from the next? I think the answer to this is 'There is nothing that makes one project significantly different from the next if all the components remain the same'. Is this a round about way to getting to the definition of insanity? The definition of insanity is doing the same thing over and over and expecting different results. - either stated by Ben Franklin or Albert Einstein. So, if we want to make a dramatic change in the outcome of the projects we work on, we need to make dramatic changes in the components of the project. Let's focus on what level of change on which components will produce the most dramatic change to the outcome....spending about 5 seconds on this thought, I'm pretty sure that any change to any technical component (OS, development environment, etc.) will have only a marginal impact to the result - so moving from Windows to Linux might be a positive, but will it dramatically impact the outcome - probably not. I guess the answer is something we already knew - a change in the human element will have the most dramatic change....(to be continued at some later time)

Wednesday, February 14, 2007

Yahoo! Pipes
Figured I'd post this 'interesting' tool from Yahoo. Basically it allows you to combine RSS feeds, dissecting some of the RSS data to match up with other selected services and provide a new RSS feed.....opens a lot of possibilities, but based on the current list of pipes it seems that the real possibilities might be limited at this time and the idea at this current time a curiosity more then a useful development (but I could be wrong). There seems to be MANY possibilities, but with RSS feeds at the mercy of the provider, the stability is questionable as well as the consistency. As with everything else - times will tell.

Tuesday, February 13, 2007

Want to stand out?

If you want something to stand out make sure the surroundings are consistent. A tree in a desert gets your attention more then a the tree in a forest. The same holds true for project plans. Your plans should follow a consistent look and feel and the critical/risk areas need to stand out by being different - or consistently different. For example: if you plan has major topics (environment, requirements, development, etc) and sub tasks (under environment you have review, design, implement, etc.) - the areas that you want to stand out should contain a specific, but unique, major topic - for example: RISK AREA or MAIN FOCUS AREA or MAIN PROJECT VALUE. This ensures that everyone's attention, from end users to upper management, are directly drawn to the area of the project that you feel needs the most attention. If each project plan you present is different in format,major topic areas, included data, etc. - the attention you want focused to one area will be spread across the entire plan as people try to understand the plan you are presenting.

Friday, February 9, 2007

When the roof leaks....

When the roof leaks, at least you know it's raining outside. It's easy to create project management processes- what's difficult is implementing them and correcting them in place. There is no such thing as a perfect system, you can either extend resources and dollars in trying for perfection OR put a framework in place that will provide the base processes with some focus in areas that could potentially cause issues - then let it rain and see where the leaks are. Keep the patch kit handy, set people's expectations and be in the mode of continual improvement.

Wednesday, February 7, 2007

System Complexity

The definition of complexity - is complex in itself (from WikiPedia - Why should it matter to a project manager? Simple - the more complex a system the more likelihood of system issue in not only the end product, but also the requirements gathering and development. Complexity could come in the form of the number of external systems connected to, amount of data, diversity of data, amount of business logic, levels of security, precision in information required AND any combination of those or other items that add to complexity. The problem with complexity is that it grows exponentially - add another if statement, another layer of security or one more external data feed and the complexity could grow by an order of 10 or 1,000. What to do? Basic approaches include:
  • System Reduction - removing all but the bare system essentials
  • Iterative development - provide short duration deliveries and/or short duration projects
  • Component creation - delivery is in the form of base working components that can be built into complex systems like building blocks (objects??)
No matter how we approach a complex system - it's still a complex system and this needs to be taken into consideration when estimating timelines, etc. For each task a level of complexity should be recorded that adds to the time and cost factor. (a 2 day task at a high complexity rating could have a buffer of 5 additional days to complete - where a low complexity rating adds 1/2 day additional to complete). Instead of 'adding a standard buffer' - it's adding a buffer based on task complexity.....maybe????


To much work and limited resources - welcome to the real world. As effective as you might be, chances are you have more to do then there is time to do it. Make sure that what you do focus on is the correct priority - simple age old advice. What is the most important item to complete? What is the customer expecting? or demanding? Do you have items that are time constrained (need by a certain date)? What items, when complete, will reduce on-going work load (items that improve productivity)? If you need to, put a spreadsheet together to help your prioritization process:

Monday, February 5, 2007

Under Allocated Resources

What are they doing?? That is an important question. As important as it is to review over allocated people (you scheduled them to do to much) - under allocated resources also present a risk area. Are they working on tasks that you're not aware of - this may lead to identifying those missed tasks in your plan that could cause major problems. are they working on other projects? if so what is the risk of their other activities impacting your project? When things are not going as well as expected, one comment one often hears is that people are not working hard enough - what if this isn't true? What if people are putting in all sorts of effort, but it's not being tracked....did you under estimate work effort? if so how under estimated is the entire project? did you miss important tasks? What if you're sharing resources with other projects and at some point you require more of their time - how much is available. I think the point I'm trying to get to is that Under Allocated Resources (according to your plan) present the same level of risk - if not more - then Over Allocated Resource. With over allocated resources, you know what the issue is - under allocated??? better find out.

Saturday, February 3, 2007

Project Success

How can the overall level of project success change dramatically from year to year??
Here's the link to the article from the famous Standish Group:
It seems a little odd to me. I would have imaged a steady curve over time, but to go from 23% to 15% to 18% for failed projects seems a little off (over a six year period). What is being measured? I'm sure they're taking a systematic approach to their method - but it still doesn't make sense......

Friday, February 2, 2007

Thin Slicing - what makes certain people highly effective

In Malcom Gladwell's book blink - the concept of 'thin slicing' is introduced - this is where people react (or act) based on minimal information - aka instinct. He present numerous instances of this type of behavior and how very effective people have very effective instincts. I don't think this is a new concept, but it is presented in a clear enough way that even I understood the implications. What's makes one person more effective in their position then another? Why is it that one person can be 10 times more effective then another - even when both have the same background, training, etc??? Perhaps it's this idea of thin slicing. Let's look at programming, a problem (aka requirement) is presented - programmer A provides a high quality solution in 1 hour and programming B provides a standard so-so solution in two days - why? Both had the same time, information, experience, etc....perhaps programmer A has the advantage of being able to instinctively better understand the problem and solution instantly - programmer A was able to visualize both and therefore all that had to be done was 'code to the vision'....where programmer B needed to take the traditional approach of reading, defining, trial and error, etc.....

If this is what the difference has been between GOOD and average programmers, then our approach of hiring, training, etc. needs to change - right? Perhaps we hire the person with better instincts for the job instead of the length of prior employment, direct experience, etc? Can you simple test this via on site tests? giving the candidate a test in what they will be doing and seeing how they 'instinctively' approach it? How do you train to make someone more instinctive? can that be done?

Here's some interesting info on INSTINCT from WikiPedia:

Thursday, February 1, 2007

PageFlakes - a neat tool
- a very impressive personalized web start page. Not only can you customize the page to your liking, you can add numerous RSS feeds, custom PageFlakes such as WikiPedia, Calculators, etc. In addition, you can add a Flake to your web site - such as the WikiPedia flake above. Great idea and VERY well implemented.

Does the goldfish grow as big as the tank?

We all know about work extending past expected delivery times (to often the case), but how often are we confronted with early delivery? I mean early quality delivery? There's a saying - not sure from who - about the goldfish growing as large as the tank. When providing estimates, we all assume that there is some 'buffer' built in. How often is this buffer consumed by 'additional' work being provided, beyond the expectations? Over delivery - should this be considered the same type of issue as under delivery? In many aspects the answer is .... not sure. Over delivered product is often looked upon positively by all and sometimes nejavascript:void(0)eded to 'make up' for prior under deliveries. However, by over delivering on something, is there a risk that other critical tasks are not getting the attention that they should be. Is over delivery often on items that are non-critical? easy to do? clamorous and/or fun? Is this an indication that some core task, that is more difficult to delivery, is not getting the attention it should be?

I think the overall response to either over or under delivery is ensuring that a task's delivery expectations in regards to date, quality, results, etc. need to be clearly defined and if we (PM's) notice a consistent over delivery - that we need to review all work to make sure proper attention is given to all and that the over delivery is not a sign of other issues.