Tuesday, January 30, 2007
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.....
Sunday, January 28, 2007
Very interesting Article: http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
and Henrik's home page: http://www.crisp.se/henrik.kniberg/
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
Thursday, January 25, 2007
and great book:
Wednesday, January 24, 2007
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.
Monday, January 22, 2007
- "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.
Saturday, January 20, 2007
What should be tracked in a Communication Plan?
Here's the link:
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.
Wednesday, January 17, 2007
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.
Tuesday, January 16, 2007
Monday, January 15, 2007
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.
Saturday, January 13, 2007
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.)
Friday, January 12, 2007
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.
Wednesday, January 10, 2007
Tuesday, January 9, 2007
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
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.
Monday, January 8, 2007
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
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
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.
Wednesday, January 3, 2007
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.
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!
Monday, January 1, 2007
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........
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.