Can you really measure work effort?

Is there a way to truly measure work effort? The time it takes of x period of days/weeks/etc. to complete a task? We typically record our time at the end of a week (or more) in some system for costing, but how accurate is our memory at the end of a busy week? And how truthful are we about the time something actually took to complete? Many times our recorded hours are based on the original estimate - this ensures that we are not criticized for under estimating OR rushed the next time we provide an estimate (if it becomes understood that we always over estimate by some percent). Cameras could be set up to watch us, but could they capture our thought process? or take into account how effective we're working during certain hours?

Without the comfort in how a person records work effort, how can we estimate future work effort? Perhaps there are other ways to measure, a way that will 'derive' work effort. Can we develop an equation based on quality of what was delivered, duration of the task, some effectiveness scale for the person, complexity of the task, etc. Still all subjective to some degree, but observable and not dependent on the person that is estimating the work effort and also doing and recording the work. This means that the first few times a person works, we don't request an estimate from them, but just observe to gauge them and then using an equation develop their projected effectiveness and derive plans form that? This is how cannon's are gauged for accuracy, take a guess aim, fire them, see where they land and predict for the next round - constantly adjusting after each firing.....

Linked Article: Scrum and XP from the Trenches

Very interesting Article: http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
and Henrik's home page: http://www.crisp.se/henrik.kniberg/

PowerPoint: turning point of effective communications?

We've all been there - putting a PowerPoint presentation together and wondering how we can fit all the information into a slide while making the font big enough for people to see. We are so consumed with putting the information in and the background colors and cute clip art chunk that we forget what we're using PowerPoint for. It's for communicating an idea right? Trying to provide the reasoning, background data, direction, goals, etc. of something....but what that something is, is often transformed into something else because of the tool we're using. Edward Tufte (yes a hero of mine) has written an Essay on PowerPoint:
That's a must read for ANYONE using the so-called tool - here's a Wired version of the Essay: http://www.wired.com/wired/archive/11.09/ppt2.html

There have been some interesting uses of PowerPoint - the most interesting I've found is from former Talking Head's David Byrne - http://www.davidbyrne.com/art/eeei/index.php

Here's a small poll - how effective do you think PowerPoint is?

Personally, I have stopped using PP unless forced into it by threat of physical harm or reduction of pizza during lunch time meetings - and when I do use it I often add Stick Figures to make it more meaningful. Good, but bloody, stick figure fight: http://www.youtube.com/watch?v=RfQcE6haSPI

Managing: The art of the absurd

In management, as in parenthood, it's not so much what we do as what we are that counts.
Richard Farson

great article:
http://psychologytoday.com/articles/pto-19960501-000040.html

and great book:
http://www.amazon.com/Management-Absurd-Richard-Farson/dp/customer-reviews/0684830442

What is complete?

In real life software development, a project task's completeness is often determined more by the due date then by the completeness of the task. We are often lured into a comfortable sleep at night with a base understanding of what complete means and we assume we all share the same assumptions - well IT'S TIME TO WAKE UP! In a project plan we happily enter tasks that are required to complete a project and assume that once all tasks are complete, with the occasional newly discovered one, that the project is complete. What does complete really mean? And how do we track it in a project plan? Complete is defined in Webster's dictionary as 1 a : having all necessary parts, elements, or steps - all? all? here we can enter into a fuzzy logic discussion that will never end. The weakness in MS Project and most PM applications is that it does not provide, at a task level, what complete means. A tasks is typically defined by start/end dates, name, ID, description, person/group assigned and work/duration. BUT what defines when the task is complete? or complete enough? or over completed? Hopefully we're all beyond tracking percentage complete (gee, I'm 99% complete - that only took a day, so within another 5 minutes I'll be 100% - yea, right) - but is there anyone tracking the exact meaning of completeness at a task level? For example: a task could be the delivery of a simple report, is complete the delivery of the report? the delivery of the report and test plans showing it works? the delivery, test plans and acceptance by the PM or User? Shouldn't we be defining this in the task somewhere? Let's not get carried away about having to be COMPLETE - let's think about the benefit of delivering something complete enough. Let's take a requirement document. There is not such thing as a complete requirement document, not even at NASA. There's always some question, some white-space, some un-noted item - the question is, at what point is the value of the document sufficient and any additional work applied to it move it in the direction of diminishing returns?

I think the short answer is that a tasks completeness needs to be defined and noted, in the project plan with the task, and the level of completeness determining the end of the task needs to be defined by a combination of the PM, the end user, the sponsor and the person/group performing the work. The defining of the task completeness needs to occur prior to the task starting to remove any pressure to either reduce the work effort to complete on the predefined date or extend because the assigned person is 'nervous' about the quality of delivery.

Increasing Gains

I'm just finishing up The Tipping Point:How Little Things Can Make a Big Difference by Malcolm Gladwell. Great book and I highly recommend it. Malcolm discusses, at some length, how contextual settings have a major impact on how people respond. A good example of this is the theory of Fixing Broken Windows that was used in the mid 1980's to address the critical issues facing the NYC Transit system. article titled Broken Windows by James Q. Wilson and George L. Kelling, which appeared in the March 1982 edition of The Atlantic Monthly. The title comes from the following example:

"Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars."

(the above is copied from Wikipedia article: http://en.wikipedia.org/wiki/Broken_windows)
The simple association of this theory with how quality affects software development was to easy for me to trip over and want to write about. This same theory could explain why quality, if focused on during software development, really focused on such as via Test Driven Development (TDD) - results in the entire quality of the product being exponentially improved, far beyond the quality improvement measure taken. It also explains why the opposite occurs, where quality is removed or reduced to ensure additional time for development or to get the product to market sooner, that a small reduction has a major negative impact on the entire product and typically does not provide the additional functionality or time to market advantage desired. Since the real improvement to product quality, which in turn has productivity improvements through reduced coding corrections, etc., is based on how people react to a contextual feedback - I would imagine that it would be near impossible to measure what the potential change is outside of performing a series of live tests - creating a couple of dummy companies that are tasked to produce the same software product with various levels of quality processes included. This is something like the novel from Tom DeMarco - Deadline. Anyway, my take away from the book is fix those windows and keep on eye on other signs of disarray that WILL impact quality and productivity.

Communication Planning

Do we even have to plan communication? YES! How else can you ensure that risk of miss-communication is mitigated? What if a critical resource is not updated to an issue? Finance is not informed of a project related billing change? YOUR BOSS IS NOT TOLD OF AN ISSUE PRIOR TO FINDING OUT FROM THEIR BOSS? Better think of the impact of what miss-communication can have on a project: coordination of resources, issue management and logistics are the key areas of risk. Ever lose a week because someone didn't know that the preceding work was complete sooner then expected - so you end up losing any productivity gain you might have experienced ('Gee - no one told me the product was ready for testing...'). Ever spend days explaining why an end user didn't have access to their application for an hour ('...gee, I need to know when I'm not able to use the product so I can inform the staff to fall back to paper files for our order taking...').

What should be tracked in a Communication Plan?

Here's the link:
http://spreadsheets.google.com/pub?key=puDAkq4iYr87FQBl5PfejUg&output=html&gid=0&single=true&range=A1:G6
The basics: What, When (trigger point), Who sends, How is it sent, to Where is it sent to, Why is it sent and What is expected.

Rate your tools

Colin Powell's Complete Leadership Presentation via Zoho

Impressive! Zoho.com

It's always the right time...........

.....it's always the right time to do what's right
Dr. Martin Luther King Jr.

When I think of ethics, the first thought in my mind is Dr. Martin Luther King. So, I was both amused and disturbed by the PMI.org's Code of Ethics: http://pmi.org/info/AP_PMICodeofEthics.pdf document. Who but a bunch of Project Managers could ever attempt to take an idea like ethics and make it into a 6 page document , the more they try to define it, the less they actually do. If you want to explain ethics, morality and courage all one needs to do is watch Dr. Martin Luther King's 'I Have a Dream' speech - that is what should be linked from the PMI site. How do you ethically approach a project? a co-worker? any situation? If you need to rely on a 6 page document to define ethics then there are much deeper issues that need to be addressed. Ethics isn't what you do, ethics is what you are. I'd like to see a PMI Certified Manager create a gantt chart around that.

Keep Paddling!

Some time ago I took an Ocean Kayaking lesson around Bear Mountain/West Point. The instructor gave some very useful advice - 'When the water gets rough, the worst thing you can do is stiffen up and stop paddling, the simple act of paddling provides stability'. Because this advice is so deep and concise I have nothing to add to it.

Colin Powell - Great Man/Great Leader

For a complete set of Colin Powell's lessons click here: http://www.blaisdell.com/powell/

To read Colin Powell's bio in WikiPedia click here: http://en.wikipedia.org/wiki/Colin_Powell

Good Project , Poorly Done - what to do?

A good project is one that ultimately adds value to the company. Some projects reduce costs, some don't seem to add value or reduce costs - I'll get back to these in a future post. What I want to discuss in this post is a Good Project (one that adds measurable value) executed poorly. A good example of a good project is iTunes - easy to see and measure the value added. Value Add is determined by the hard $'s returned on investment and the softer, tough to measure, $'s through brand recognition, secondary benefits (for iTunes it would be another reason to by an iPod, etc.). A good example of a poorly executed - good project - was/is MSN (like most of Microsoft's projects - good idea bad execution).

SO - back to Good Project - Poorly Done. What to do?? A lot depends on when the fact that the project is being 'poorly done' is caught. Was it during requirements? Execution/coding? Implementation? Go-live? Or is it live and a bomb? Obviously, the sooner caught the less costly the solution and easier to resolve. However, regardless of when it is caught the same basic steps need to take place:

• Realize that there is an issue: often the toughest part of the process. EVERYONE needs to understand that there is an issue and that some corrective action needs to take place. Often there is a feeling that some more effort, a few extra hours, etc. is all that is required, perhaps - be careful not to be to pessimistic or to optimistic.
• Triage: quickly determine the issues from a high level perspective. This will help focus the corrective activities. Don't stop, unless necessary, corrective activity that people are taking at this point, since they might be making positive progress.
• Review the issues with ALL stakeholders, determine the real impact on the project value and start determining the corrective areas of focus.
• Stop - Breath - Plan: This is where the PM needs to get down and dirty. Don't rush, but move fast (some quote I heard, but not sure where/who). You need to quick switch the teams focus from fixing to thinking. There's a typical reaction to a problem - work harder - the real solution is often to take a step back, think about it, plan a course of corrective action and aggressively execute against the plan.
• Involve everyone - get all project related resources involved in the definition of the issue and steps to address it. Additional resources, equipment, etc. should be determined by the corrective plan and cost/benefit analysis (needs to be done) AND SHOULD NOT be determined by gut feel or base re-activeness.
• Constant/on-going review: throughout the corrective stage it's important to reevaluate the product to determine if there are other issues and/or gaps. Be objective, but keep your eyes open, the mistake that got you to the near failure point is often an indication that there is a base problem that could have caused other and/or deeper issues within the project.
• Understand but don't blame: Once the corrective action (well planned) is underway, the time is right for an evaluation of the root cause. What caused the issues within the project? are they specific to this project? to the team? company wide? Be objective, be thorough, understand that someone will be upset with your findings - most importantly be honest and brave. Don't associate issues with any specific people, first understand the root cause and keep it non personal. Once the facts are in, the corrective action to the root cause should be apparent to all and those that have the power (higher ups) need to understand the issue, the approach to correct and the short and long term consequences of their corrective actions.

The most important thing to do during a crisis is stick with the process. It's often a mad rush to fix, but in doing so, the issue is often made worse. PM process, etc. are put into place for the bad times not the good (if everyone did everything perfectly all of the time there would be no need for processes, etc.).

What should be included and tracked in a Project Tool

I recently started to use QuickBase , which I would highly recommend, and modified it to manage what I thought would be the most valuable project info - so, I figured that I would share that EXCITING info.

• Base Project Info - name, start/end dates, description, project manager, company (that project is being completed for)
• Tasks - duh - of course
• Issues - Any issues found during the testing phase (any testing phase) of the project.
• Resources - who and what they do
• Risks - yep, can't live with them, can't live without them - the typical info including potential of occurring and impact if they occurred
• Change Request - what the change request was, who requested it, approval indicators for all parties, impact to project (cost and scope), etc.
• Deliverables - what are the project deliverables - and their status (open, met, removed, etc.)

There are details for each of the above items, such as date of entry, subject, description, who it's assigned to, etc. With this information at hand and a real time tool instead of a enter/print/forget tool (MS Project) I see the management of projects just as difficult (tools don't fix people or problems), but the communication, overall picture/status and at-your-fingertip information much easier.

Duration of a task

An often overlooked but important question is 'How Long should a project task be?'. The simple response is 'as long as it needs to be......' but wrong. Project tasks are tracked to reduce the risk of slippage - so the task duration needs to be such that it can be definitively tracked and provides soon enough feedback to allow the PM to react to if it is slipping. An extreme example is a task being the same duration of the project. 'Sure, I'll get that done by the end of the project.....' - yep, right. The right answer to the task duration question is dependent on a few things: how long is the project, how critical is the task, how much time can you afford to lose with the task such that it does not greatly impact the project delivery. The way I approach it is that a single tasks, for a mid to large size project, should not be less then 1 week or more then 2 weeks - BUT - it's all dependent on how critical the task is. If tasks of much less duration are tracked, the management aspect becomes extensive. There was one project where a team member submitted a 10,000 task project plan, with many tasks tracked down to the hour and 1/2 hour......my questions was 'what if someone burped??'. Each task needs to be for a definitive amount of work, have a definitive deliverable (not 'the task when complete will provide 80% of the functionality' - what??) - have an assigned person, etc. If the defined work is less then a week (say a day) can it be grouped and rolled into associated tasks. If a task is more then 2 weeks can it be divided into sub tasks, etc. A CRITICAL task - such as installation of software needed to go live - that takes only 3 hours, should be tracked......no need to say 'gee I guess we forgot something' during the go-live process.

There should be some more 'scientific' approach to task durations, but with the complexity of planning, defining tasks, calculating impacts/risks - I can't see a good scientific approach being as effective as a PM with experience.

Project Management - Funny??

mmmmmmmm.....I don't think PM is ready for prime time humor. Can anyone name a PM that did stand up comedy? Successfully?

Horizons

The most dangerous strategy is to jump a chasm in two leaps - Benjamin Disraeli

Why are there different levels in an organization? CEO, VP, Director, etc.??? In some cases it's to delegate responsibility, one person can only manage so much. In a mature company, I think, it's to provide a different view of the Horizon, which is needed to develop long term strategy and direction to a growing company. For Example:

• CEO - horizon focus is 1 1/2 to 3 years
• VP - horizon focus is 9 months to 2 years
• Director - horizon focus 6 months to a year
• Manager - horizon focus 3 months to 9 months

There should be an overlap from level to level to ensure a continuous strategic landscape and the summation of all the strategies at each level should reflect a smooth progression of an overall corporate/company direction. Some levels might be transitional in cases where a corporate focus change is needed and planned for (Kodak's change from film to digital).

What is a Horizon gap? Simply a missing level of strategy caused by the person not performing their role properly. For example the CEO is focusing on the 1 to 2 year strategy and the VP is focusing on the day-to-day issues. The transition from the different horizon points is missing and the risk of failure is significant.

Normalization

Not sure how far I will get with explaining idea..but for some time I've been thinking about database normalization and how THAT type of approach can be applied to project management. DB normalization is usually held as a standard to how well structured a database is.

From programming 101 I learned that Relational Database Management Systems were based on set theory and defined by a mathematician - E. Codd. There are 6 or 7 or 5 1/2 and one more Normalized Forms (depending on what you read, I always remember it being more then 1 and less then 11). These normalized forms are used to describe how the physical database structure is implemented and used as a bench mark. It's amazing how a few sentences can have such a deep impact (lesson to self - the more I yap the less I really know). SO - the question I've been tossing around is, can PM - or someone for PM - define a simple set of rules that can be used to define how to approach PM and how to judge a well laid out plan? Probably not since people make $ from selling a lot of books and if a person could define PM with more then 1 or less then 11 well defined rules then the entire PM industry might close shop. But let's see if we can tackle at least one.

First normal form (1NF) is a normal form used in database normalization. First normal form excludes the possibility of repeating groups by requiring that each field in a database hold an atomic value, and that records be defined in such a way as to be uniquely identifiable by means of a primary key.

WOW - this might be tougher then I thought. Let's see: Each table has a primary key, not so bad. So for every task, risk, change request, etc., there is a unique identifier that you can reference each entry by. For instance, a task as a Task ID that within the project can not be repeated - NOT SO BAD!

Eliminate repeating groups? What's that mean?? Let's use tasks to define: A single tasks can not have a field (task name, start/end dates, resources, etc.) that repeat. So, for example:
Task ID: 1
Start Date: Jan 1, 2007
End Date: Jan 3, 2006
Task Name: Buy some Jelly
Resources: Meade

would be valid, but

Task ID: 1
Start Date: Jan 1, 2007 and Jan 8, 2007
End Date: Jan 3, 2006 and Jan 11, 2007
Task Name: Buy some Jelly
Resources: Meade

would not be, since the start/end dates have more then one entry - not bad. What about resources? I could take my dog shopping - but that would be okay as long as for the entire task duration it's me and my dog and not for part me and then another part my dog assigned to the task (if so then it should be broken into sub-tasks such as 1.1 drive to store and 1.2 buy the Jelly where the dog would drive and I would buy the jelly) - WOW - not bad again.

I think we can get around the atomicity like more then one resource - as long as we consider all the resources listed as being a single unit needed to complete the task (Am I stretching it here?) Enough thinking for one day - I'll need to sleep and think about the Second Normal form.

WHAT A GREAT DAY!

I made a contribution to Edward Tufte's Web Site!

May not be a big deal, and I'm sure they would take anyone's scribblings...but THEY TOOK MINE!

Here it is - I know as soon as they re-read it, it'll be removed:
Interesting reading, especially in that we all seem to have the same issues, etc. in easily representing various levels of project management information. I think the general sense is that MS Project does not fit the bill and Gantt charts in general display to little info for the space they consume (which is unfortunate since PM and Gantt charts are often seen as the same thing).

The downside to wall charts and any printed information is that, as soon as the project information is printed, it's dated/old and most likely out of date with what is actually going on. The need to have the chart/tool/etc. reflect future planning instead of past occurrence or set schedule (like a train schedule) is probably the biggest challenge in the design.

The tool I most heavily rely upon is MS Excel, I've created some simple spread sheets that show multi-level information by Project such as: Component/Area, Task/Function, Status, Health, Est/Act Start/End Dates, Ownership and a timeline. Here's the link: http://itprojectguide.com/downloads/files/PTimeLine_Example.xls It's a bit dated, but I think it provides a general idea. This provides for a high level that can be drilled down. It would be nice to have this DB driven so the rollup/drilldown could be automated based on entered info instead of the manual approach.

-Meade

Cowpens- Excellence in Leadership

Battle of Cowpens - 1781 - Excellence in Leadership!
History, especially military history, provides many examples of effective leadership. Daniel Morgan, a relative unknown by name, is attributed with managing the most tactically creative and effective battle during the American Revolution. (Mel Gibson sort of portrayed him in his movie 'The Patriot'). This, as in many cases, is an example of fact being more interesting then fiction. Daniel Morgan was one of the wilder ones of his time, tough, fighter, business man, etc. - no real military training outside of experience. He was involved in MANY American adventures and battles. What makes him such a good example, especially during the Battle of Cowpens? The basics: Communication, knowing his resources, knowing what he was up against, understanding risk, being brave and leading.

• He knew the overall Strategy of the American side: Don't be destroyed, fight only when you have a high probability of winning.
• He knew the local strategy: Make them come after you, stretching out their communication and supply lines - wear them out.
• He knew his men: The militia could/would not stand up to a determined British attack.
• He knew his opponent: AGGRESSIVE!

He was able to formulate a plan, that took weeks (or months) prior to the actual battle, he was patient and focused on the goal and he instilled faith in his command even when they spent most of the time 'running' (or advancing in the other direction). For a great book on the battle read: A Devil of a Whipping: The Battle of Cowpens. The most important leadership quality of Daniel Morgan was his knowledge of communication: he did not rely on memos, others speaking for him, standing on a stump and talking at the troops - he went from person to person - over and over - and communicated directly with them. He told them what to expect, what they needed to do and what the results would be if they did their job - in person. WOW! What manager can say that - in person - eye to eye. Did it take a lot of effort and time? Yes. Did it take him away from the tent and 'big picture' thinking? Yes. What it did do was reduce risk and increase the probability of succeeding in the area of importance. It's hard to argue with success.

Sparklines - a good example

Sparklines - beauty in information communication as only Edward Tufte could describe www.sparklines.org. There is no way I can add to what he has presented and I'm not dumb enough to try. Buy his book - Beautiful Evidence - visit his site http://www.edwardtufte.com.

What I would like to discuss is how Sparklines provides a good example of Web 2.o - beyond the buzz. As you can see, Sparklines provides a new/unique approach to data presentation. When I first read this, I started to search on the web to see if anyone has implemented this yet and to my amazement (not really) there was a LOT of information AND OPEN SOURCE code for Sparklines - http://sparkline.org/ (notice the missing s). Of course there's an entry in WikiPedia - http://en.wikipedia.org/wiki/Sparklines
and many other links to free and for-fee sites.


One man's idea, an entire internets approach to providing more information and code to implement that idea - a community around an idea - isn't that Web 2.0? I think so. It shows the strength and depth of what is happening out there. What does this mean to Project Managers? To Software Developers? First thoughts that come to my mind are:

• Cool! Now I can add Sparklines to my web sites and projects
• Guess no one will be making $ off of Ed Tufte's idea
• Now this is WEB 2.0!
• The day of making generic functions for profit is over, once a good idea hits the Internet - and if it's good - lots of other people will provide via open source
• What a great way to Determine if an idea is good - let's see if it is being done in Open Source........

A PM and Software Developer now have a source to determine if a project and/or components of a project are seen as valuable. You can determine the value by the distribution, you can get the best implementation by searching for feedback, you can see various forms of application. You can reduce cost/effort by utilizing open source. YOU CAN REDUCE RISK!

Some things to think about.

• If your project is not using an 'open source' friendly technology (.Net) then are you adding effort and cost to a project based just on the technology selected? What would be the difference if you selected PHP?
• Part of the project should include tasks for identifying components/functionality and determining if you can utilize any in the open source world.
• Make sure your project is not competing against an open source implementation - I think $ will be more in integration (Publishmash ups) and implementation rather then in pure development (how can you compete against free?).
• Make sure you address the various open source license agreements out there.
• If you haven't moved from the 'built here' to 'off the shelf' thinking - you're way behind. As a PM, part of your job is to ensure feasibility to check risks, etc. If you can't see the wave, that means you're looking in the wrong direction.

Go - Read - Think