Go towards the light

There’s enough to do (for most project managers) just keeping existing projects on track and moving, the additional burden of ongoing process improvement is more often than not pushed to the side since many consider it a nice-to-have/low-priority effort. I think this is one of the biggest failings a project manager falls into. We (PM’s) are paid to reduce risk and as a result provide for a higher probability of success – right? If you believe in that, than our primary function should be process improvement even at the risk of the current project. Think about it, a failed project today in an effort to ensure dozens of successful projects going forward as compared to pushing a failing project through and then tackling the next project about to move into failure status soon after. We need to continue to move towards improvement, move towards the light at the end of the tunnel to ensure that when we leave, we leave a better environment then when we started. Step back, take a breath and look at the big picture.

It’s about forgiveness

Projects come and go, many are soon forgotten and some stay in people’s memories for a long, long time…usually the more painful ones, the ones that ruin careers, ruin friendships, marriages, dreams. Some people have problems moving on and often hold life-long grudges against those they think were the main culprit for those evil projects. Fortunately for me all of my projects have been very successful (just kidding).

I think we all owe ourselves and our current and/or former team mates a once a year complete clear the painful history, put the smile back on our faces, lift a beer in celebration of the attempt forgiveness day and I think its most appropriate around the Holiday Season (Merry Christmas and Happy Hanukah and Happy Kwanza and all the other year end holidays)…learn ye lessons from the past, but let the painful memories that stunt our growth and happiness be forgiven and forgotten.

(image from http://blogs.phoenixnewtimes.com/uponsun/2008/12/curtains_a_christmas_carol_at.php)

The greatest obstacle to overcome – desire

I’ve been in different companies and in different positions and the one common theme throughout all is the outright avoidance for the #1 obstacle to change – desire. A company might be doing great or it might be on the way to nothingness, the people could be top notch or very mediocre, the work environment ranging from open and happy to slave-like and demeaning…processes non-existent to CMA Level 5 – there seems to be no common theme in what makes the people in the decision making position have the internal desire required for real improvement. Desire is the one base element needed for change, change is a very uneven, scary place to be, one that many people avoid at all cost…but for those with the desire, one that could provide the greatest benefits – but sometimes not.

The biggest push back often heard is that the company is doing great, or at least good enough, stay with the known and continue to gain rewards. That’s the old wait and see the train coming at you syndrome.

Another is the knowledge that a bad or poorly executed change could cost the person their job…this is actually the same as above – wait and see the train coming. If you’re not gaining and you’re treading water safely why swim? Sharks! Currents! Endurance! Sooner or later someone comes knocking at the door looking for big results.

The downside to being a project manager is that you often don’t have the decision making position and at best have a strong influence on the person/people that do. There’s no process to add desire, you can’t provide a drink for it (even though a few beers at the right time could help) and you can’t influence it beyond where the decisions makers want to go.

Solution:
Serenity Prayer:
God grant me the Serenity to accept the things I Cannot change;
Courage to change the things I can
And Wisdom to know the difference;

Why Quality Assurance ain’t

When you give a person an excuse to do less than the best, often times they accept it as the norm. QA is a good example of providing an easy out. Why put the effort into checking your own code, ensuring what you do is acceptable and going out of your way to program defensively when you can have someone else do that often painful, trying to get toward perfection type of work….

I have no real evidence, but I’ve seen enough evidence to show that the number of QA resources is directly proportional to the poor level of coding. You might say additional QA people are brought in to compensate for the quality of coding, I think the number of QA resources is more driven by allowed budget and the higher the budget the power the code quality….sounds strange, but I really think it’s true.

I’ve always felt that a good QA group would indirectly contribute through audits and improved processes, however – in most cases – they are designated as testers, fed bad apps after development mangling. So, at the end of the day, the hoped for gains from a QA group are often lost through the misuse of them and the re-direction of quality from the source of issues to the QA group who gets stuck at the end of the pipe instead of helping front-load quality. My suggestion: get rid of QA and lets see what the results are, I would wager improved overall quality within 30 days.

You always lose in a zero sum game – always

In the real world, where real things happen and theory hides in books there is little to gain from any interaction where one gains at the others lose. This applies directly to projects and project management.

Let’s look at a simple example: a project to improve market share in the hamburger market. The project includes creating a fancy website, iphone ordering and email marketing blitz…you currently have 30% of the market and hope for 40%...a healthy 1/3 increase. Could be worth an additional $50k a month if you get it…sounds beautiful. So you build the site, you create the iPhone app and you blitz the hell out of people until they start to associate you with the world’s best hamburger and you reach your goal….you might have spent $100k doing all of the including increasing your capacity to provide the additional hamburgers everyone wants. What happens day 2? When your competitor follows your lead or someone on the outside gets excited when they see the lines of customers waiting for your hamburgers? You didn’t really increase the overall demand, you just adjusted the finite demand…your initial costs and on-going support costs not just for the site and iphone app and email blitz, but also for the increased hamburger making capacity is still there as the hamburger seekers start to look elsewhere, the profit margins reduce and your new Mercedes is getting towed away by the repo man.

When you wrestle with any finite/zero-sum item you’re essentially spending to gain something that will eventually be lost – if you were able to increase overall demand, say from 1 in 10 people wanting hamburgers to 1.5 in 10 people wanting them, even if a share of that increase drifts to another hamburger provider you established a bigger pool to work from. The potential of going back to the demand where you started or even less is reduced.

What does any of this have to do with project management? Think of resource sharing, think of budget constraints, think of sponsor sharing – anyone or item that you have to timeshare with any other team puts you in a zero-sum game and continually puts you at a higher risk of failing at the end of the day. What you gain today in a finite pool will cost you more tomorrow to keep and cost you dearly if you begin to lose your share.

Escape Velocity – aka kick starting a project

Starting a project is often as difficult as ending a project (successfully). In my opinion, a projects success is largely based on the psychology make up of the company and more importantly the direct team. A highly motivated, functional, capable team can perform wonders…a team without the cohesion, dedication and determination needed for the given project will easily and quickly fail. One of the critical stages in a project is the start of one, a given project that is delayed, pushed to the side, ignored, frowned upon by management and/or delivery team will fail before it starts – how motivated can a team be when they are given a project no one wants or cares about, a self fulfilling prophecy. To help ensure a successful project delivery, a good project manager will recognize the need to get the team ‘pumped up’ about what they are doing, motivate them from the start, aggressively start the project and do what is required to keep the momentum going…just like basic physics, a stationary or slow moving object requires more energy to move…a project that is blasted off, heading in the right direction and one where all team members are locked in step will be have a much higher potential of success…no planning, Gantt chart print outs, pounds of documentation will replace the team’s determination positive or otherwise. Projects succeed by the will of the team – period.

Old technology is everywhere

I’ve been through the Old Iron Mainframe to Mini to PC transition, the standalone computer to everything/everyone connected phase, the computer as a tool to the computer is everything transition and now I’m seeing the computer is everywhere/everything to the smart phone switch.

Just recently I finally broke down and brought myself an iPhone. The famous, mind numbing, can do everything device that I thought was over played/over hyped. Well, I was very wrong and I am now realizing the smartphone switch that is/has-been happening very fast and very dramatically. Everyone is connected to everything from everywhere all the time. There’s good and bad in everything, but lets focus on the good:

• no more missed calls or being out of touch
• no more being lost
• no more not knowing what’s going on from your friends level to the international level
• the ability to shop smartly
• the ability to plan smartly
• the ability to adjust quickly and inform all
• the ability to pay without cash or card
• the ability to be entertained anywhere
• storing memories, sharing experiences

Basically anything today that you have to ‘go to’ to use is being removed to be with you – or part of you. It’s an amazing shift, bigger then (but because of) all prior technology shifts over the last 50 years.

When the client is wrong, everyone is wrong

I have experience working for both internal and external clients and all levels of them (from the bottle washer up to the cook). There have been many good relationships and some bad ones….but at all times I had the understanding – based on the age old saying – that the client is always right…but what happens when the client is wrong. Well, the way I see it is, if the client is wrong EVERYONE is wrong and everyone ends up paying for it in some way, refusal or inability to pay for services, reputation and self-esteem. When signing on to do a job we sign on to deliver a successful product, one that meets/exceeds the client’s needs and provides something positive for them. Some project managers see the delivery of what was asked in a timely/cost-effective manner as the only real measurement for them…how wrong they are. When you sign on for the job, you’re joining a team, you’re part of the group effort to make something positive happen and part of the blame if it doesn’t meet ALL of the client’s needs. Bottom line – in my opinion – if you don’t want to be part of the team don’t sign on, if you’re not at the level where you have ‘some skin in the game’ than there’s a good chance you’re not fully committed and that could be start of something bad.

Make your own something

Another great idea presented on FLOSS Weekly (http://twit.tv/floss92), MakeBot (http://makerbot.com/) – basically an open source 3d durable product printer. You create or use another’s design to print out the object in 3d, could be used to actually make something useful (scissors were mentioned on the show as something to be worked on). Imagine the ability to make simple replacement products, used by car repair shops, home hobbyist, designers, toy makers, etc. Potentially reducing the need and reducing the cost of making simple things overseas…and it’s under $1,000 TODAY! Imagine in a few years what this could mean? Perhaps a device that will bring creativity back to the US shores….however you look at it, its one of the more interesting Open Source initiatives around (beats another CMS).

How Google Wave – hello touchy feely, goodbye fire-and-forget

I’m a firm believer that an effective project manager (PM) needs to be an effective communicator. A PM cannot hope to positively impact a project without being able to successfully communicate with the team (including sponsors and users) and to get the team to openly/honestly communicate with each other. There are many stumbling blocks to effective communication, including:

• Conflicting interests
• Common terminology and understanding
• Differing personalities

One of the causes of the above stumbling blocks is proximity – people are people and people tend to form into temporal tribes whenever possible (cliques for a better term). When people ‘tribe up’ they tend to form their own interests, terminology and tribe personalities…each adding to barriers of effective communication…so, why am I saying that Google Wave is the start of something good? Simple, its primary function is to allow individuals to group contribute to ideas (Wave’s) and the ability to easily add in people from any ‘tribe’ to review how the conversation progressed (replay)…the base assumption here is that the PM would open the idea to anyone/everyone with any related interest. This allows for the crossing of traditional IT boundaries: programmers, sponsors, testers, end users can get included directly or indirectly (polls for example) into an on-going discussion. The crossing of the boundaries starts to reduce the barriers and helps personalize each individual’s concerns, interests and understandings. NOW – Google Wave in itself will not help, no tool really helps – tools enhance, the PM and management need to enforce/reinforce the need to openly/honestly communicate and to include/invite ALL people with interests into a conversation – Google Wave allows for this conversation to take place over time and distance…and allows for the reaching out to larger groups through polls…it’s not a fire-and-forget approach of email, its and ongoing live discussion with the ability to incorporate polls, documents, pictures/mockups, etc….

Done

Just browsing through Yahoo Group’s eXtreme Programming forum  and came across a discussion on what Done is and when you have Ron Jefferies and Kent Beck contributing on the discussion you can’t help but gain or be amused. Kent Beck’s definition is ‘requires no further investment to get the return I anticipated’ – simple, defined, open, accurate. Done is done as determined by the person making the decision. You can try to definitively describe what your anticipated return is through TDD, predefined plans, requirements, automated burn charts, PMO’s, etc…but it takes the decision maker, at the time she/he designates to determine Done…Done could be a sign of success, realization of failure or acceptance of good enough. Books, classes, endless blogging (this one included) can try to better define done…but Mr. Beck, Master of his domain, has defined it best…

I now know how to prevent most project failures – thank you Capers Jones!

The secrets are out, the underlying reason why projects fail, some so badly that they result in litigation cases. The glove fits, the DNA was matched, the evidence is overwhelming AND the amazing part is that this is well known and communicated information. Let me start by saying that I had the privilege of attending a conference that Capers Jones presented at, one of the most amazing moments was when he told all of the CIO’s present (from some very large companies) that they are making the same mistakes that have been made for 20+ years and are directly responsible for them…since the cause/effect and method of correction has been known and identified long ago…and the room fell silent.

Here’s a link to the entire paper that will cure the curse of project failure:
http://www.itmpi.org/assets/base/images/itmpi/privaterooms/capersjones/Defenses2008.pdf

in Summary:

• Estimating – either poorly done or rejected. Just amazing how knowledgeable business execs/owners can turn a blind eye to hard data AND then question why the project failed.
• Change Requirements – the typical case of the scope continuing to grow without control and without taking the impact to time/costs into account. I think metal stress was a known test in the 1800’s…200 years later and IT/Business hasn’t found the book.
• Quality – as stated in the doc: defect prevention, defect removal and defect measuring – abc’s of QA.
• Project Tracking – as stated in the doc: Achieving specific and tangible milestones; 2) Expending resources and funds within specific budgeted amounts.

WAIT A MINUTE!! It can’t be that simple!?! These are known and easily implemented changes!?! Short Answer: Yes!

Well next time a project fails don’t go looking for Godzilla tracks, just dig Capers Jones article back up and bang your head against the wall.

The tracks are down, now deliver the goods

It might be the changes I’ve seen in the last 25 years, but where I’m standing now software development is more about implementing than discovering. Gone are the days of trying to build solid development approaches, computer connectivity, easy system setup, quality tools, mass data storage, etc. Work is still being done in those areas, but the foundation is well in place and understood. Just think about how long it takes to set up a simple website? And what technical ability is required…I would say 10-15 minutes and minimal skill…example Square Space (http://www.squarespace.com/).

Do we need to start modifying our approaches, standards and life cycles to meet the implementation phase? Going from a track laying to goods delivery type of thinking? Simple answer is Yes! More emphasis needs to be placed on short term business benefit, time to market and quality messaging….put those work boots away and put the pick back in the shed.

(image from: http://whitemtncentralrr.editme.com/RailroadHistory)

Tracking is not the same as doing

There seems to be some level of buzz over FitBit (http://www.fitbit.com/), a device that tracks the calories that you’re burning as well as how much you sleep. The base idea is to let you know how your exercise regiment is doing as well as how well you are resting…but not the number of calories you consume. I have to admit that I’m slightly an exercise freak (working out 5 days a week) and at times have become obsessive, given that, I find no real value in this product (but best of luck to them). The first thought that came to my mind was that it will give people the false impression that they are actually doing more by just wearing the device – letting them know how many calories they are burning and perhaps justifying that extra spoon of sugar in their coffee…which bring us to the project management discussion of the day – Tracking is not the same as doing……..

I’ve been in a few companies where the CIO’s action to improve IT is the implementation of a PMO or more stringent project management. All well and good, since in order to determine what the root cause issues are and to know if you are improving over time the first thing you need to do is measure where you currently are…HOWEVER, in many cases the implementation of the tracking (PMO or other) is it, no further changes, just using the collected data to show people that work is being done. Well, guess what, the difference in productivity between the day before the PMO was implemented and the day after is the same - there is a theory that there is some short term improvement to productivity by just measuring it – something about giving the workers either a feeling or importance or fear to help them improve – short term only….Same idea as the FitBit, measure all you want, but the most important thing is to improve.

• don’t lose the goal of improvement and 
• don’t let fancy charts and interesting numbers get in your way
• don’t feel good about where you are
• don’t feel you deserve something just because the reports look good
• always be on the lookout for way to improve 
• make sure your primary focus is on people – the key to any real improvement

Can Project Management survive Anarchy (aka Scrum or KanBan)

Anarchists are those who advocate the absence of the state, arguing that common sense would allow people to come together in agreement to form a functional society allowing for the participants to freely develop their own sense of morality, ethics or principled behavior. (via http://en.wikipedia.org/wiki/Anarchy)
Question: Can Project Management survive Anarchy (aka Scrum or KanBan)?
Short answer: A good Project Manager Can

I am (always have been) very pro-Agile, especially those who adhere to the base Agile Alliance Manifesto. (http://agilemanifesto.org/). Who wouldn’t support it? I mean really support it?
Short answer: Those who feel threatened by lack of control…

In my opinion, a GOOD project manager is a person who helps in any way to ensure business value is being provided. For those who feel some form of anarchy is needed to shake off the shackles of corporate over management, I’m with them. HOWEVER, in my experiences, those who push the most to shed the chains of corporate oppression often have their own chains in the making, something to be very wary of when supporting such a movement. The best approach is to uncover the underlying drivers and realize that at the end of the day we’re all humans and we all tend to make the same decisions as those before us (in other words, people who seek freedom of choice often try to bind others to their preconceived choice).

What is this blog post about? My on-going discomfort with where Scrum, KanBan and like movements are going, more about putting a certification business model in place than actually providing a path for improvement. I always get comfort in reading Kent Beck or Ron Jefferies posts, they seem to keep to the original goal of the Agile Manifesto where others tend to seek monetization for a recycled idea with a different sounding name.

I got the Wave

http://www.cnn.com/2009/TECH/09/29/google.wave.beta/index.html
http://www.pcworld.com/businesscenter/article/172822/google_invites_more_testers_to_ride_wave.html

Evolutionary more then revolutionary and I think (once I get use to it) that it will set the pace and direction for other major communication tools.  I've always felt that IM and Email are basically the same, and any way to easily track communication, continue the conversation and add to it would be GREAT! Google Wave moves in the right direction.  There's potential for some information overload...but it all comes down to how people use and adopt to it.

WOW – Twit.TV/Floss Weekly with Linus Torvalds

Floss weekly hosted by Randal Schwartz and Jono Bacon is kicking up some great shows. This week’s show is an interview with Mr. Linux - Linus Torvalds. As Jono Bacon said ‘…opinionated without being an ass..’. Not a deep insightful discussion on Linux, but a GREAT discussion with a leading software developer and some of what makes him who he is. A must listen to for anyone interested in IT.

http://twit.tv/floss88

Alan Turing - hero

Thank you John Graham-Cumming for bringing Alan Turing's story to light and petitioning the government to do the right thing!

http://www.twit.tv/213

http://www.theregister.co.uk/2009/08/18/turing_pardon_campaign/

Kent Beck on FLOSS Weekly

For those of you who don’t know who Kent Beck is, well its time to learn: http://en.wikipedia.org/wiki/Kent_Beck. Basically he’s one of the founding fathers of the Agile movement and the person behind Extreme Programming (XP) and all that goes with it…a real IT hero.

Kent was recently featured on FLOSS Weekly a great podcast about the open source community: http://www.twit.tv/floss87. This is a must listen to show, topics range from his view on Agile, Test Driven Development (TDD) and open source…all interesting and controversial points. What really caught my attention and reenergized me was his comments about a programmers need to take responsibility and to be accountable – plain and simple, something that every developer should reflect about in regards their dealings with others. His focus was more on the soft skill arena (psychology) and how it plays into the maturing of a programmer…

Dr. StrangeFramework or how I learned to stop worrying and love the layers

Part 6 – Wrapping up
I did not cover all the layers (not even thinking about down to the linux kernel) and did not go greatly in depth into any one of them…I just wanted to provide an overview of the layers I encountered/put-in-place in the development of a prototype that may someday become the next open source project management tool. My overall feeling is that frameworks FORCE you to code in a standard way providing FREEDOM/FLEXIBILITY to focus on the product being delivered and those corners of the code where 80% of the complexity is (which sometimes needs to be handled outside of the various framework/layers). I w as happily surprised overall with my ability to decouple and with the reduced coding required to accomplish what it is I desired to do…

Dr. StrangeFramework or how I learned to stop worrying and love the layers

Part 5 – ORM
What is it? I don’t think there’s any definitive answer, but basically ORM (Object Relational Mapping) abstracts data into objects (or attempts to) – so multiple tables providing data to represent a single project is treated as a single object with in the code: project name, project tasks, project notes, etc. each stored separately in the database (RDBMS) becomes a set of related objects within the PHP code…what my hope was, was that DataMapper would provide the interface to define the data layer and then kick back a hierarchical single object (Project) that would provide methods to access the underlying related data (project notes, etc.)…well, it did make accessing and manipulating the data easier – the top-down object hope was not there (could be my misunderstanding of ORM OR the difficulty in providing it). Once again following a framework forced me to setup the various data tables in a standard format and it did handle all of the underlying SQL/DB requirements and probably reduced my code by half (at least). Without having a LARGE database, its difficult for me to say what the performance impact is…I would assume there’s some impact…but I’ll leave that to others to provide the insight on…next, wrapping up

Dr. StrangeFramework or how I learned to stop worrying and love the layers

Part 4.5 – the PHP Framework
Before moving on to the data layer, I first need to discuss the PHP Framework. I’ve moved from no-frameworks to frameworks for everything – WHY? Simple, it forces you to code to specific standards making the code cleaner and more maintainable. Frameworks also reduce the amount of code that has to be done – the less coding the fewer bugs. The first real framework I’ve used since web coding was CodeIgniter (http://codeigniter.com/) – about a year ago I decided to try a MVC framework (Model/View/Control) and did enough research to determine that CodeIgniter was stable enough and flexible enough for me…so far I’ve been very impressed with it and the associated community (a very important thing to look for – without support the best framework is useless). SO, to move on with the story, without thinking twice I used CodeIgniter for the PHP framework, the one dissatisfaction I had was the data model layer, I wanted something more than creating SQL code and returning array bound data…I wanted ORM (Object Relational Mapping) which I was hoping to use to reduce the amount of manipulation to set up the arrays to feed to the json encoder. It didn’t take long to find DataMapper (http://stensi.com/datamapper/) – an add on for CodeIgniter providing the ORM layer I was looking for. ..next step – ORM

Dr. StrangeFramework or how I learned to stop worrying and love the layers

Part 4 – json
Json is basically a universal standard way of formatting data (http://www.json.org/) which provide some benefits over XML (still being argued somewhere)…why not XML? One reason was that jQuery directly handled json and another was that everyone is talking about json….simple as that. In Part 3 I discussed how I started the json approach using static json data pages, the next step was to move from static to database/code provided data. Creating a json output in php is relatively easy (depending on the PHP release that you are on) – there’s a simple function json_encode(data) where data is typically a series of arrays/sub-arrays containing the data you want encoded. So, json encoding was the easy part, the difficult part was getting the data in the the array/sub-array/sub-sub-array layout that you wanted…next step, the data layer.

SANS - The Top Cyber Security Risks

Interesting paper on security issues: http://www.sans.org/top-cyber-security-risks/

Dr. StrangeFramework or how I learned to stop worrying and love the layers

Part 3 – decoupling
To keep the layers decoupled as much as possible, I decided not to have any PHP code directly populate data within the page ANYWHERE! No matter how easy it is, the complexity and maintainability is impacted when you do this – you end up with HTML/jQuery/PHP code all over the place in the same code file…some people use Smarty or like frameworks, but all they do is basically add another layer without reducing the coupling. SO, I decided to use json…I started with some static json data pages and used jQuery (THE BEST) to read the data, parse and populate the page, overall a very pleasant experience compared to what I thought it would be. The toughest part was properly formatting json, once done I was satisfied that for the most part the presentation layer to the application layer were decoupled…next step, json

Dr. StrangeFramework or how I learned to stop worrying and love the layers

Part 2 – there’s no end like a front end
I wanted to focus a bit on the user interface, my prior attempts using trees and such were ok, but just ok. I knew I wanted to use base html/jquery (no Flash), so I started at jquery.com, looked at some of the addons and took a swing: http://www.itprojectguide.org/projectmatrix/ci171/matrix. I only focused on what I considered the main screen, the project page and overall I think it’s reasonably user friendly (something that might change once I add in all the base project related fields). The layout is basic, using tabs for projects and sliding panels for project details…seems like a simple/clean design. The biggest challenge was uniquely identifying fields by project, so from tab to tab the changing of a ‘start date’ field for instance would only be updated for that specific project. As a new project is added, a new tab created with the project identified fields…as always jquery made most of the work easy and coding amount/time small….next step, decoupling

Dr. StrangeFramework or how I learned to stop worrying and love the layers

Part 1 – the setup
I haven’t had a heads down coding position in years, however I continue to develop small websites and ‘play’ with code on side projects and hobbies. A good part of the fun is pushing myself to learn new technologies and approaches, the days of happily coding in C, C++, VB or classic ASP are long gone.

I’ve worked on two open source project management tools (info can be found here: http://itprojectguide.org/main/products/Home) the first a branch from another open source group and the second an attempt to provide a better interface and a better code base. I learned a lot from both, but was left unsatisfied, mostly due to the design, but also the cumbersome underlying code, PHP can be pretty messy if you let it. One of the things bothering me the most is the coupling between the different layers (DB to PHP to HTML) and the need to refresh pages to display updated data (loading a heavy page of about 80k to add 100 additional characters seemed a bit to much).

There are MANY options to writing code for a web site, PHP being the most popular since its probably the easiest to learn and abuse…I often hear Python/Ruby coders trash PHP all together, the way I see it, any language can be distorted, some languages make it easier than others, but it’s the developer who makes the difference, I’m more than confident that a good programmer can make clean, effective and maintainable PHP applications – as clean as Python or Ruby can be….next step, the front end

When you plans are right, but have nothing to do with reality

I’m just starting the book ‘The Guns of August’ by Barbara Tuchman – about the planning and first month of WW I. The most interesting point so far is that the French Plan (Plan #17) took no account of actual intelligence gathered about what the Germans planned. The French basically developed a plan based on current theory and molded what the Germans would do to fit into that theory (‘no way the Germans would march through Belgium and attack out exposed flank…no way…’). Sounds familiar right? developing a plan based on some current theory, regardless of what facts about known…probably a good example that project managers encounter every day is the time required for testing – break/fix. Forget about the last 10 projects that required the same effort to QA/break-fix as what the coding took, let’s assume this time the QA/break-fix effort will only be 25% which is perfect since it will allow us to release the product in time for the big holiday season….yep, planning and execution are truly different when you refuse to take fact into consideration.

Seeking the just good enough?

I recently read through issue 3 of PragPub and found the article Clone Yourself (http://www.pragprog.com/magazines) – the focus was suppose to be on (I think) building a better career through following the pattern of perfect process…one section deals with the idea of not getting the best person for the position, but a person that’s just good enough given that you have the right processes in place to ensure their success (if the process is good the person can be mediocre). I’m not sure if there has been any subjective research on this matter – but I would have a difficult time agreeing to it. The author references some past experience where they got the best and they didn’t work out, I would say that perhaps the definition of best was incorrect, what do I define as the best person for a job?:

• someone who is enthused about what they are doing (gotta love the job)
• willing to do what it takes to get the job done
• great communicator
• team player, but not a compromiser
• independent worker
• intellectual capacity for the job (knows and/or ability to learn)

Some traits I would think disqualifies a person for a job:

• inability to work with others – at any level
• very narrow skill focus – unless the skill is so narrow that it requires such a narrow focus
• to many preconceived, unshakable, predefined concepts

Overall, the idea that a person is only needed to follow a set of processes leads me to think that the job is probably not a real development position where something new is being developed, but where the job is no more involved than a data entry position from the 1970’s. No matter how hard PMI or Agile Alliance or any other group tries to define a set of steps to ensure success of a building process, they have not yet succeeded and as far as my theoretical thinking can take me, can never succeed since they would have to finitely define every potential step for every development effort that has or WILL take place…even Madame Marie on the Asbury boardwalk cannot make that assertion.

Another example of open source knowledge

http://www.scribd.com/doc/8545174/Whys-Poignant-Guide-to-Ruby

If there's no incentive to selling books/knowledge (talking $ here) then people who have a tendency to want to write them will find other avenues (aka the web) - this is one great example of that. Not only is this is a great into to Ruby its a great read...

Happily looking stupid

Being able to look stupid has many advantages in project management

I’ve recently been thinking about one of my biggest strengths: willingness to look stupid in front of people. I think I first realized this power when I first started to play the harmonica with local bands at bars (some of which were actually ok as long as I was outside the bar)…

Being comfortable with looking stupid has allowed me to:

• Ask the stupid question that everyone think everyone else knows, but no one really does
• Question why the go-live dates are being pulled in, when all indications show that the project delivery dates should be moved out
• Ask a top developer why the suggested confusing/mind-boggling approach is the best
• Not show up for mandatory meetings, when the meeting agenda is about setting up other meetings or when no agenda is present
• Not stay late when there’s no other reason than to look good in front of the boss
• Ask HR why such wonderful company policy about safe/happy work environments and balanced work/family time is never really inforced
• Question why cost cutting is the focus instead of opportunity taking
• Keep trying to promote change based on issues and not symptoms
• Ask why exceptions that happen all of the time are considered exceptions

Looking stupid has not always been easy, but as time goes on and I feel more confident in myself the more looking stupid seems to be the right thing to do

change to IT Project Guide - Open Source look/feel

I haven't really updated the IT Project Guide - Risk Management project in a while (outside of some reported bugs) - thinking about moving to a new look: http://sourceforge.net/projects/itpgrm/

compare to what it is now:

http://itprojectguide.org/PMBase/risk/home

??any thoughts?

process corrupts, absolute process corrupts absolutely

Why are there continued changes in IT project management and SDLC processes? And why can’t developers and project managers define a single process that both agree on? Are there that many conflicting goals that prevent this from occurring? I think the root cause is the idea that a single process can be defined and put into place today, based on yesterdays findings and that will be beneficial tomorrow. No plan to put a stagnant process in place will never work, problems change, environments change and most importantly people change.

I think this is the root cause for continued process change, for example KanBan, which is based on Toyota’s car manufacturing process, just as Six Sigma was developed by a Motorola process break through. If you look closely enough, new processes are old processes re-purposed, re-named or slightly re-factored…why? I think the reason is that, once a process is put in place it goes through a phase of being formalized, dumb’ed down so everyone can follow, forced on to every new project and (most unfortunately) used to measure people’s ability and commitment to the company….exactness to steps instead of intent is followed. As the process becomes more out of step with current needs of both projects and people, they are targeted as being old and wrong and new ones are ‘discovered’ and implemented.

We need to get everyone (aka management) in line with continued process improvement (or whatever the new term for that is) and ensure that a meta-process is in place to continually review and improve and replace as needed.

KanBan - http://agile.dzone.com/news/introducing-kanban-flow-and

(image via: http://timmonsgalleries.com/FA-rep.html)

Netflix Culture Presentation

Great presentation with a lot of great ideas!

Culture

View more presentations from reed2001.

How we learn - reading other people's discussions

I've been following a great discussion on KanBan at: http://tech.groups.yahoo.com/group/extremeprogramming/

you have some VERY INTERESTING people involved including Ron Jefferies and Kent Beck...I would highly recommend any interested in hearing some top authorities discuss an important item (project approach) to join and listen in.

Front loading success

In a recent article, Tom DeMarco stated that Software Engineering is an idea whose time has come and gone, basically stated that heavy management /oversight is mostly needed for projects that have minimal benefit and those projects with the most to offer require less…and that the real effort should be focused on ensuring the right projects are selected and then on anything that will help those projects have the highest probability of success.
If that’s true, than we need to ensure that we focus on ensuring that all processes in place allow for the least friction to the project team while ensuring focus is on front-loading success factors into all projects: from selection of the project, team selection and management selection. Just as QA’s real benefit is ensuring quality processes are in place, from requirements writing to delivery, a project manager’s real benefit to an organization is in ensuring the right project is selected and that it is given the proper start in life to succeed…unfortunately most PM’s are still looked to for delivering daily project updates and bad news about slipped dates. (just like QA is looked to performing post code complete testing)…
No matter which project management process or SDLC is selected, no matter what quality team is used or outstanding platform – a ill conceived project will fail and potentially cause collateral damage to the business.
We, PM’s, need to remain open minded to new ideas and be brave enough to speak out when needed.

Tom DeMarco Article: http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

(image from www.ac-orleans-tours.fr/.../insurgent3.htm)

They built it the way I would have

Just as a disclaimer – I’m as Smartsheet associate – someone who could potentially make $ when someone follows a link I have and purchases the use of Smartsheet, either it hasn’t happened yet OR Smartsheet is holding out on my million $ check – whatever case has no impact on the following.

I’ve been involved in two separate open source project management tool projects, together they have about 5,000 downloads from SourceForge and neither one would I really use in a business environment (but they were great for learning php, CodeIgniter, SourceForge and 100 other interesting things).

When I think project management tool, I think of:

• ease of use
• ability to easily modify what information gets captured
• NO Gantt charts
• enhancing communication
• single stop for all project related information

The most effective tool I’ve used, prior to Smartsheet, was a spreadsheet (MS Excel and Google Docs) – both provided the flexibility and control I wanted, but neither provided real automated reminders, document storage or ability to easily modify look/feel…

When I first started to use SmartSheet it was a spreadsheet on steroids, but mostly a spreadsheet. Over the last year a lot of new functionality was added, including the ability to perform some functions on each cell. The overall user experience is simple to the touch, making one think that there’s little power under the hood. HOWEVER, I’ve come to rely heavily on it (even if others have not – yet). Adding new columns, changing drop down values, add sub sub sub tasks, having dates programmatically change based on prior tasks date changes, timed or event driven email updates, reminders, etc. are all there. It take the hassle out of working with a plan and lets one focus on working the plan.

I’ve worked with and tried about a dozen other PM tools…but I’m still not seeing anything that would compare to Smartsheet….at least for my current needs.

Improvements through dumb’ing down (aka simplification)

The Wii, Google’s planned new OS, the web interface (compared to client/server), PC’s, the iPhone (compared to laptops) all have an interesting thing in common – improvement through simplification (aka dumb’ing down)…it seems to be a cyclic experience, where things (anything) grow in complexity until someone rediscovers the base benefit, removing the excess/gold-plating and providing a major improvement through reductionism rather than increased functionality…pure beauty.

I think we’ve seen the same process take place a few years ago with XP/Agile and since then the increasing complexity being added to the base Agile theme.

Lessons learned: Look to dumb’ing down any existing process, don’t listen to:

• that’s the way its always been done
• if we just add this one thing it would make everyone’s life better
• I think JoJo the monkey boy from Finance uses that application…so we need to spend $1 million when upgrading to support it

Be brave and cut the phatt

Only 8 seconds and in 3rd place

I haven’t been following this year’s Tour de France (http://www.letour.fr)closely, but I’m still aware enough that Lance Armstrong is in it for his potential 8th win, a huge record. As of today, he’s standing is still 3rd and ONLY 8 seconds behind the lead – this is the 10th leg of a 20+ leg race…my first reaction is ‘only 8 seconds..not bad…I’m sure he can make that up…’ and its 8 seconds out of a total of 43+ hours of racing– but in reality, if it was really that easy he would be in the lead and not 3rd place and unfortunately it could be a good indicator that the rest of the race will reflect the current standing.
Lesson learned: if you’re behind in schedule assume that unless you change something, you’ll remain the same ration behind (or worse) for the rest of the project. Don’t fall into the ‘we’ll pick up speed soon’ trap, even if you’re just a little behind schedule…if everything was going as planned or better, you wouldn’t be behind, even by a small fraction (especially since we all tend to heavily buffer the schedule).

• Don’t Hope
• Don’t Ignore
• Don’t expect good things to happen on their own…

Be alert to your own checkpoints and flags, that’s why you put them in place and react appropriately

Software Engineering: An Idea Whose Time Has Come and Gone?

A very important read:

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

Looking in from the outside

According to the stats, 2 in 3 projects are not considered successful, something I think all of us would gut feel agree with. Out of morbid curiosity, I’ve been following the outward signs of a long-running,yet-to-be-announced project failure in the CMS world…

• late 2006, initial discussion of the upcoming major release 3.0
• early 2007, sneek preview at a major conference
• early 2007, announcement that the current version will have an interim release to correct security issues
• mid to late 2007 – all quiet on the release 3.0 front…to quiet
• early 2008 - announcement of difficulties and long weekends of work
• mid 2008 – more previews, a demo site and a planned go-live in a ‘few short months’
• late 2008 – announcements of what the new version will not support
• early 2009 – commitment to more timely updates – and the quiet again
• a little bit later in 2009 – discussion of a beta
• now…..who knows

The above is a rough timeline of events. From the communication (mid 2006) to the most recent the indication was that there was only a ‘few more months’ of work prior to the v3 release….a few months of work that has so far taken 3 years to get complete. Sounds to famliar...

I’m just wondering that with the current number of open source communities, if there is some valuable lessons to be learned from following their progress……..

When in doubt stick it out

There’s an old saying in boxing (or really any martial like art) that ‘when in doubt, stick it out’, mostly referring to throwing a jab instead of doing nothing in order to keep the opponent busy. Well, the same holds true for project management. It’s always better to send out a ‘straw man’ (rough sketch/best estimate) then nothing at all. It provides a base to start a discussion from, provides a catalyst for others to react to, displays some form of action and direction AND above all sets a tone for the project. Don’t hesitate or be to conservative, others will take that as the tempo for the project and follow suit. Afraid that what you send out will cause a commotion? Well….that’s part of the PM job, isn’t it?

(image via: http://www.boxingdaily.co.uk)

Edge cases – here be dragons

Let’s be clear about one thing: there is no such thing as perfection…which inversely means that there is always imperfection. The land of imperfection is a place to tread softly. Imperfection is always rampart in project assumptions and those areas where developers feel the most comfortable: clearly defined logic. There are always edge cases, the non-norm where more mystery then factuality exists, always logic that tries to account for everything, but…….never seems to be able to. Technologists may try to convince themselves that everything is definable and that everything definable is programmable and everything that is programmable is complete…but the base assumptions are always wrong, nothing is completely definable, nothing defined can be completely programmed and nothing that has ever been coded has been complete.

Where is this going………..

A project manager needs to be aware of those who start to wander in search of perfection, such as:

• 100% uptime (or even 99.55555%)
• Complete data integrity
• Performance never exceeding some sub-second time
• Ability to identify people from bot
• Ability for bot to replicate people
• Performance testing
• 100% geo coverage

And steer the people back to safe shores where obtainable objectives are achievable. Stay aware, watch for developers straying and sponsors espousing grandiose ideas. You can’t stop the explorers and doing so might stop some new discovery…but don’t let main line business projects go in search in areas where dragons abound.

New Real Estate Open Source project – help wanted

OK, so I’ve got a new scratch to itch, this time it’s real estate related. I’ve worked for real estate companies for about 10+ years and always felt that the life cycle, though understood by many, was never implemented. Most people begin their real estate search on the web and within the first 2 weeks of their search begin a relationship with a real estate agent. Most often the relationship with the agent is through a referral (family or friend)…So…search the web…personal referral to an agent…why doesn’t the web search lead to the client/agent relationship? Simple – most real estate sites are listing focused, which is nice, but does not provide the easy transition from interest to relationship building required for most real estate transactions. One of the major drawbacks into finding a real estate agent is the lack of information about the agent, typically it’s just a picture, name and phone #. What I would like to do is build a product where the focus is on the agent, providing relevant information for the consumer to select one and providing the agent with a social network environment where they can nurture the relationship…here’s my first pass at the spec: http://itprojectguide.org/myAgent/myAgentv1.pdf

And SourceForge site for the project: https://sourceforge.net/projects/myagent-re/

If you’re interested let me know. meade.rubenstein@yahoo.com

A fish DOES rot from the head down

After confirming with a reliable source (Myth Busters), I can confidently say that a fish does rot from the head down (with from disclaimers about the fitness of the dead fish):

Sunfisher
Senior Member
Registered: 09-27-08
Posted 12-10-08 12:01 AM
Living on a lake in MN, I think I am qualified to explain this one. The skin, scales and the rest of the outside a fish provide a barrier that inhibits decomposition. If this barrier is damaged anywhere it will appear that decomposition has started at that point. If the fish is undamaged, the eyes are usually the first thing to go.
Link: http://community.discovery.com/eve/forums/a/tpc/f/9701967776/m/5641933599?r=5641933599#5641933599
(you might have to log on to view)

So, how does this apply to an IT Project? There are probably a few ways you can apply this metaphor, the one I think most applicable is that a project will rot from the Initiation phase down. If you don’t get the initiation right, which includes: goals, scope, constraints, involved people – than the rest of the project has a higher risk of rotting.

Wireframe – when less is more

The goal of a wireframe design is to provide the review with a sense of the overall user experience, ensuring that what’s delivered is functional, usable and attractive…period – nothing else, not color schemes, not what images to use, not wording, not the glossy look and feel of a finished product. The wireframe needs to be closer to an old fashioned architectural diagram than a glossy magazine, the most essential reason behind this is to help the review focus on what the effort is trying to convey. A simple experiment (mind experiment if you want): put two diagrams in front of any person, one a black/white sketch and the other a mocked up webpage with deep rich colors and interesting images and see where the focus of the conversation is…pretty obvious and a pretty entry level IA (information architect) mistake.

I put most of the blame for poor IA on the tools being used, use photoshop and you get gloss, use visio amount of detail information that you build in comes at a high price of time and effort – a good IA tool needs to provide quick, easily updatable, clean designs…just so happens I’ve recently come across a wireframe tool that provides the clean, sketch like look along with the ease of use that I’ve always hoped for - Balsamiq Mockups: http://www.balsamiq.com/ Not free, but worth the $’s. I was able to sketch out a 20 page site in about an hour, go back through and refine in another hour…the ease of the initial creation invited revisions…making for a better end result.

Software development isn’t the only thing to suck

Intro to the Boeing Dreamliner story: http://www.msnbc.msn.com/id/31504462/ns/business-aviation/

Boeing Dreamliner - 2 years late and a lot of excuses (via http://en.wikipedia.org/wiki/Boeing_787):

• blaming a shortage of fasteners as well as incomplete software
• cited problems with its foreign and domestic supply chain for the delay, especially the ongoing fastener shortage, the lack of documentation from overseas suppliers, and continuing delays with the flight guidance software
• said that insufficient progress had been made on the factory floor to complete work that was originally planned to be carried out by suppliers
• unforeseen delays
• another delay, this time caused by the incorrect installation of some of the structurally important fasteners
• will face additional delivery delays of up to six months, because Boeing is not expected to reach its target production rate
• stating that the first flight is postponed "due to a need to reinforce an area within the side-of-body section of the aircraft"

Sound familiar? I’m no critic and don’t have any airplane building experience (outside of models), but it’s sort of nice to hear that industries other then IT/software have their problems too. So, the mighty engineers aren’t so mighty after all and the giants of efficiency and getting things done also fail. It’s like dancing on someone else’s grave…but, let’s get the dance over and see if there are any lessons here.

To many new things:
new technology (carbon fiber) + new process (offshore’ing the work) + new relationships (either new offshore companies or at least new types of interactions with them) = trouble.
To many new factors to properly control. Maybe the offshore activities should have been tried with existing manufacturing and any new R&D type of product first needs to be developed onshore with known/skilled resources.

If you’re drinking a gallon of coffee don’t blame the dog barking for lack of sleep:
Fasteners, fasteners, fasteners – seems to be a recurring theme (at least on the face of it). If the same issue keeps arising, make sure it’s the root-cause issue and then attack it. In the IT world you often hear about Quality issues or integration issues and then management focusing on hardware (or whatever they’re comfortable discussing) to correct it….find the real problem, doesn’t matter if its within your comfort zone, and deal with it.

Most of the times, you don’t need a crystal ball:
If you’re having problems throughout the entire project, don’t wait until the end to tell the users that their expectations are not going to be met. Fewer features, lower quality, slower performance or whatever the impacts are from a problematic project need to be clearly communicated out to the sponsors and clients as soon as possible – but not before the confidence in being able to deliver to the new date and expectations level are set.

Security - don't start a project without it

Alleged Hacking-Terror Effort Thwarted

All Pain and No Gain

Clients are still unhappy, your manager is not patting you on the back, the developers grumble about everything, the projects are still not getting done timely or with quality and you’re running out of beer. Project Managers often go into new situations with the best of intent only to find that process changes provide poorer results then what existed…why is that? In most cases the answer is simple – the wrong problem was addressed. The Gantt chart, resource allocation , bug tracking, task management wonder tool was used like a circular saw in a ice cream shop – resulting in havoc, despair and unemployment.

Political, territorial, ego sensitive, insecure, unsure, over bearing people (aka The Team) who have trouble being in the same room with even themselves will have no problem entering time estimates in project plans or nodding their heads in process review meetings, BUT try to get them to truly change to a more productive and cooperative relationship with others, based on a Gantt chart, is like trying to pry a icy cold beer out of my end-of-week tired of the nonsense hands, it ain’t happening.

Rule #1 – know thy problem, don’t listen to people when they’re telling you the issues, LISTEN to them, are they naming names, are they talking about past attempts that failed, are they sneering at you, do they seem distracted, focused on everything but their area of responsibility, are they there or mentally removed? Look at people’s desks, how they interact, the environment they’re working in and how they treat each other. Do the managers provide clear direction? Do people show up on time OR at all to meetings?

Rule #2 – assume you don’t have an answer, don’t come into a situation with a answer before you really now the problem (go back to Rule #1). It’s easy to look back at historic events and come up with better plans (gee, if I was George Washington I would have purchased some of the new tanks to take care of the British…) THE tough part is coming into a situation not knowing how it’s going to turn out and actually making a significant positive difference. Spend time with Rule #1 before even thinking about the solution.

Rule #3 – communication and consistency, nothing unexpected should be done and whatever is done should be consistent. Let people know what your planned changes are, tell them what impact it directly has on them, tell them the truth and consistently apply the corrective actions – if there were no exceptions there would be no need for the rules.

Rule #4 – don’t back off, but don’t close your eyes to change. Change is tough, getting people to change habits is a painful process – search out the positive and acknowledge and reward it, search out the negative and apply the appropriate correction, don’t shy away from the job…and don’t close your eyes to the possibility that all of your plans are correct, be open to change and rethinking, but be cautious about any decision to move off course – over correction is sometimes worse than no correction.

Rule #5 – realize that it doesn’t end, there’s no end to improvement, there’s no end to doing things better there’s no end to problems….

Learning Python

I’ve been spending a good amount of time recently learning Python. Why?

• ego – I want to be able to walk the walk and speak somewhat intelligently with other tech heads
  
• staying relevant – I have another 20-25 years of employment ahead of me…
  
• seems like the new Java – I never learned Java (not sure why ) and always felt left out (back to #1 – ego)
  

As a project manager, my needs for learning Python are different than they would be if I were a developer, the level and depth of understanding are different, but the need to understand the basics and application are the same. I’ve always felt that a good project manager needs to have a good technology background, this provides for insight into development and a common ground for communication. Imagine a PM with mainframe and COBOL knowledge only talking to a 19 year old php/MySQL developer…could be lots of talking going on, but little real communication.

What does learning really mean? I’ve seen a lot of people learn a lot of things, but few actually gain an understanding and the ability to apply the learning. To me, the true test of learning is the direct application (base learning) and extrapolation (advanced learning). Reading a book, typing in examples and getting expected output is just the knowledge that there’s something out there – here’s an excellent Buddhist look into knowledge: http://www.sacred-texts.com/bud/mzb/oxherd.htm ..
Another aspect of learning is understanding WHY it’s important to know what you’re studying, why other people see it as meaningful (insight into others) and why it’s getting the focus. Much of which I’m still trying to get my hands around in regards to Python.

So, what steps did/am I taking in learning Python? Basic google’ing Python was the start, which quickly lead me to http://python.org/ - the official Python website. From there I moved to Active Python- http://www.activestate.com/activepython/ - where I downloaded the interactive Python interpreter (and later Komodo edit for a better editing environment). Having an interactive/interpreter made learning and experimenting a lot easier – typically a new language means a new IDE, finding a host or setting up a development environment, etc. – nice thing about Python (one aspect of why its getting the buzz) is the low pain threshold of starting. Being ‘old school’, I also purchased a couple of books – O’Reilly Learning Python and Expert Python Programming: Best practices for designing, coding, and distributing your Python software which I’m still reading. I followed the typical approach of skipping around to interesting sections and trying the code out in the Active Python Interpreter….another important source of help was StackOverflow (http://stackoverflow.com/) – tech heads ready to answer the most basic questions.

So, now for the good, bad and ugly aspects of Python – SO FAR, I see Python as a very clean, easy to use multi-platform programming language. In many ways it reminds me of Pascal, back in the 80’s (aging myself), a step in helping programmers program correctly. Being a new language, specifically developed for its currently environments, it does not have a lot of the quirks and kludges php, c# and other languages have (if I offend…oh well). The ease of learning (or unlearning and relearning) is there and the interpreter provides for ready/quick feedback. I’ve:

• .played around with creating a UI (Windows) – not a pleasant experience
  
• interacting with various data sources, like websites, files and databases – fun and easy
  
• built classes, generator functions, modules – very easy and eye opening to the strength of Python
  

I see Python (my opinion) as a solid clean language – good entry for non-tech heads and experienced programmers alike (similar to BASIC), the typical evolutionary but not revolutionary steps of technology. Would I recommend it as a platform for development? Yes (depending of course on the actual needs), would I recommend it as a learning platform for new techies or those needing something more than excel – YES. I’m not sure of its stability or performance issues – but, seeing its implementations and uses would expect them to be at an industry strength level (outside of high use sites like Facebook – but I could be wrong).

Next steps for me include:

• finding a project that I can use Python on (currently looking into creating an opensource requirements management project)
  
• looking into Python web development frameworks (seems to be a decision between Django and Pylons)
  
• still looking into the interesting python’ic aspects of Python. One pattern I’ve found interesting were the generators (using yield within a function) and redefining superclasses…huge improvements over what I’ve experienced in other languages…
  

If you’re interested in Python, I strongly suggest installing Active Python (about 5 minutes) and going through the Python.org tutorials…

The Product of a Self-Defeating Design Process

Good article on why corporate culture is the ultimate deforming force

Project Management exercise from StackOverflow

Here's a mindmap I put together based on a question from StackOverflow

http://stackoverflow.com/questions/922559/how-should-i-begin-this-kind-of-project

The Master and His Three Sons

There was once a great master of kenjutsu (sword) renowned throughout Japan who, when visited by another great master, wished to demonstrate the teaching he had given his three sons.
The master winked at his guest and placed a heavy metal vase on the corner of the sliding doors, wedged it with a piece of bamboo and a small nail in such a way that the vase would fall on the head of the first one who came into the room when the door was opened.

While chatting and drinking tea, the master called his oldest son who came immediately. Before opening the door, he felt the presence of the vase and its position. He slid back the door, put his left hand through the gap to catch the vase and continued opening the door with his right hand. Then, clutching the vase to his chest, he entered the room, shutting the door behind him and replaced the vase; he came forward and greeted the two masters. 'This is my oldest son', said the host smiling, 'he has learnt my teaching well and one day he will undoubtedly be a master of kenjutsu.'

The second son was called and he entered without hesitating and only caught the vase at the last moment: it almost landed on his head. 'This is my second son', said the master, 'he still has a lot to learn but he is improving every day.'

Then the third son was called. Entering the room hurriedly, he was struck on the head by the vase. The blow was a heavy one but before the vase hit the tatami, he drew his sword and, in one quick action, cut the piece of metal in two. 'This is my youngest son, Jiro', said the old man, 'he is the baby of the family and he still has a long way to go.
______________________________________________

Question for the project managers out there:

Which son are you when it comes to risk management?

Value of Teams on mid-size projects

There’s a gray area of project size (scope and complexity) that may or may not require a team to complete, this is the focus of this discussion. The determination of what that gray area is, is a completely subjective/fuzzy call by those in position to make that decision.
Personally, I have always leaned towards having the fewest people involved in any project, this is based on my feeling that any additional communication, management or human interaction than required exponentially adds to the risk level of the project – however – I might be wrong. What if the team is well established, mature and requires minimal management? (Ideal situation of course)…what value could having more people than required on a single project?

• Higher quality product and more productive if an XP type of team programming is in place.
  
• Chance to develop a Jr. member on the team
  
• Continued reinforcement of the team model and on-going success record
  
• Direct transfer of knowledge to a backup person
  

I’m beginning to think, with the right team, on a project that can be team-developed or is decoupled enough for multi-people to work on – the leaning towards more people rather than fewer is the right approach.

Ed Yourdon - Enterprise 2.0

One of my hero's of IT....there's enough information in this presentation to keep a person busy and thinking for a VERY LONG TIME!

Enterprise 2.0

View more presentations from yourdon.

What Project Management Lessons I learned from watching bowling

Bowling is one of the few sports I can enjoy watching and I’m sure it’s a sign of my increasing age. Here are some bowling lessons I’ve learned that I think are directly applicable to project management:

• You’re known for your last lose (failure) more then all the prior wins
  
• No matter how good you bowl, know the lanes, no matter how many prior frames you had strikes in, the next frame is an unknown…
  
• Few bowlers bowl a perfect game
  
• The professional bowlers don’t look at each other much….they tend to focus on their own game and not how the other bowler is doing 
  
• No matter how geeky your shoes look, how out of date your shirt is, if you’re good people will pay you and others will watch in admiration
  
• One bad frame does not always mean a lost game
  

Standish 2009 CHAOS Report – what could it mean?

Like any other report, The Standish CHAOS report will have it issues – what defines a failure? How do you validate the sources? What does it really mean to fail or succeed? Does this represent to broad or to narrow of a segment?

These are all good and valid questions, to me the most important is the report data gathering and reporting consistent with prior years? The final #’s have little relevance (to me) compared to the overall trending….and the overall trending is interesting - more projects are failing this year than last. A lot can be read into that, here’s my take (assumptions):

• As the economy continues to slow (or remains slow) the better managers will cancel the less important project, focusing on the key business drivers (end of day a good thing)
  
• Companies are cutting resources, causing the remaining people to be overloaded causing lower quality deliveries (a bad thing)
  
• People have more of a negative view and will tend to be more critical of what is being delivered and lean towards reporting failures more than successes…one of the bigger issues with any subjective type of reporting – BUT one that can be understood and used to adjust the findings.
  

My view of the report is that it’s a great value and solid indicator of what is happening in IT – my view of IT based on the report….we need to get a lot better 32%...that’s a failing grade in my book.