Standish 2009 CHAOS Report

http://www.standishgroup.com/newsroom/chaos_2009.php Boston, Massachusetts, April 23, 2009 - New Standish Group report shows more project failing and less successful projects. The Standish Group's just-released report, "CHAOS Summary 2009," "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions" says Jim Johnson, chairman of The Standish Group, "44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used." "These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures", says Jim Crear, Standish Group CIO, "They are low point in the last five study periods. This year's results represent the highest failure rate in over a decade" In the "CHAOS Summary 2009" report The Standish Group has re-examined 10 the CHAOS Success Factors. Each Success factor is supported by one of the Laws of CHAOS. The Standish Group's "CHAOS Summary 2009" report is available free of charge to Standish Group subscribers. Non-subscribers may obtain copies directly from The Standish Group for $99.00 per copy and the offer also includes Jim Johnson's book "My Life is Failure". About The Standish Group International, Inc. Since 1985 The Standish Group, the leader in spotting future trends, has been helping end users and vendors of technology solutions prepare for the future. The Standish Group delivers fast, consistent and reliable IT advice built on a solid foundation of primary research. For further information on project studies and other trends, visit our website at: www.standishgroup.com. FOR FURTHER INFORMATION CONTACT: Jennifer Lynch Communications Manager Jennifer@standishgroup.com 508-760-3600 Ex: 22

Project Management - The shortest distance between two points is a straight line

by Meade Rubenstein

• Introduction
  

  • This is my attempt at putting a book together on Project Management.  Over the last few years I've focused on a website and blog hoping that would bring me fame and fortune.  I'm not famous or rich, but what I did get out of it was a great sounding board for ideas which for the most part were no more then echos in a cave BUT every so often there came a response.
    

    This book is not intended just for people with a Project Manager title, but for anyone performing project management  activities or wishing to.  Project Management is a skill set utilized to mitigate risks.  Project Management does not add value to a project, it prevents value from dissipating through unnecessary costs or loss of quality.
    

    I am a firm believer that:
    
    1. everyone is not suitable to be a project manager or fulfill project management responsibilities, it should not be considered a default position for those who are not good at coding
    
    2. the triple constraint, cost-scope-time, is wrong - there are additional variables such as quality and resources as well as project friction that need to be considered in managing projects.  Someone, somewhere came up with the triple constraint triangle and for some reason this bad idea stuck.  I feel the same way about Gantt charts, they might have been effective in the 1920's when they were invented, but times have changed and we need to work with real and detailed information not meaningless lines on a page.
    
    3. project management is really risk management.
    
    4. effective project management skills are required to be successful in any endeavor
    

    I hope this book provides some laughs and/or help, I will try to not write out of furstration of complete lack of knowledge.

• Chapter 1 - A world without project managers
  

  • Anytime you proactively adjust how you are working to ensure what you are working on gets done as effectively and efficiently as possible, you’re playing the role of a project manager.  
    

    Project Management has been around since the cave man, the associated processes and tools have been utilized throughout time to accomplish objectives and delivery value.  Until recently, project managers did not exist, but project management processes were used by anyone trying to accomplish something.  PMI did not invent project management when it published the famous PMBOK (Project Management Book of Knowledge) book, it categorized a very limited set of processes that have been in use. Think (aka Initiate), Plan, Execute/Control and Close Out - the same steps cave men/women used to gather wood and cook a dyno-burger.
    

    1.1 Project Management activities
    

    • When you start a new job, you focus on where you’re sitting, who you’re working with, what your boss expects from you and how you can accomplish your job.  The basics are: know where you are, know where you need to get to and develop a plan to accomplish that in the most effective and efficient way.  These are the same steps every one follows in some manner.
      

      1.1.1 Know where you are
      

      • As odd as it may sound, this is an often overlooked step for project managers.  You might start moving towards  your destination, but without knowing where you are how can you determine the overall effort to get there OR even the feasibility of accomplishing the journey?  Want to take a trip to Wyoming  and don’t know what planet you’re on…good luck.  
        

        What is there to know about where you are?  And why is it important? If you want to make pancakes, you’ll need to know if you have pancake mix, what cooking skill level you have, if you have all the other ingredients,  a pan, a stove, etc…many things we take for granted that end up causing us to deliver some pretty lousy pancakes.  I recommend performing some level of evaluation on the following to determine where you are in general and then specific for a new project:  Where you are – in General: 1.  Historic information (aka corporate culture) in regards to: scope changes during projects, willingness to extend timelines, sensitivity to cost overruns, employee turnover rates, relationships with consultant agencies. 2. Technology strengths and weaknesses, including favored development environments, supported hardware, ability to grow/expand network and servers, network/server support levels and training availability. 3. Maturity/Level of all, including developers, QA, network/server administrators, database administrators, managers, etc. 4. Key business drivers, external influencers, related market trends, this information is used to determine potential external impacts/risks. 5. Current project management, software development life cycle (SDLC), QA processes including adherence to them and any planned changes. 6. Outcome of recently completed projects – the Good, Bad and Ugly of them.   Where you are – specific to a new project: 1. Priority compared to other current projects. 2. Maturity/Level of all directly related people 

      1.1.2 Know where you want to go
      

      • If you don’t know where you’re going you will either always be there or never be there.  It’s not uncommon for projects to begin and work begin without anyone on the team OR the people providing the work to be completed to know where they’re going.  There might be some general direction given or some foggy idea of what the goal is…but often time it’s not really known.  Directions like:

        
        1. We need a website
        2. Management needs a dashboard
        3.Users are requesting a way to track orders
        
        May sound authoritative and firm, but are they really?  Need a website to accomplish what? A dashboard for who? Why do users need to track their orders? When is any of this needed to be completed by and how much are you willing to spend to get it done?  I’ve found that the traditional questions of: Who, What, Why, Where, When and How form a good foundation for determining the destination.   

      1.1.3 Develop the plan to get you there
      

      • This is often the focus point of project managers, the development of the PLAN.  When projects are failing, no matter the reason, management calls in the project managers looking for the PLAN and as everyone knows, no plan is complete without a Gantt chart.  Plans are easy to create and even easier to present, the difficult part is creating a plan that has a high probability of succeeding and even more difficult is understanding the assumptions, constraints and risks associated with the plan.  The ability to put a real plan in place, with clearly communicating all assumptions, constraints, quality levels, costs, risks, timelines, etc. separates a project manager from a PROJECT MANAGER. Don’t let anyone or any beautifully put together presentation fool you and lull you into believing that the path to success will be easy and painless.  No one knows everything or has experienced everything, any project worth doing is usually so complex that once complete will provide another chapter in chaos theory.  
        

        A solid plan needs to be molded to the people that you are working with, not only the developers, but also the sponsors, managers, users, 3rd party vendors, legal and anyone remotely involved in the project.  Each team/person needs to understand their role, what’s expected of them and when.

    1.2 Project Management Processes
    

    • If you have any involvement in project management or IT you’ve probably heard of various project management/software development methodologies, including: SCRUM, eXtremeProgramming, Agile, CMM, waterfall, etc.  Each methodology contains many interesting buzz words, various number of steps to success, never ending testimonials and detractors and no real proof of long term improvement.  More seasoned project managers realize that there’s no silver bullet and will take what works, toss what doesn’t and continually review and adjust.
      

      1.2.1Processes for Knowing where you are
      

      • Most of the Processes for knowing Where You are will be adhoc communication ones.  There are no set current processes that I know of to perform an evaluation of existing work environments.  Proceed cautiously and inform everyone of your intent.  The best way to capture this information is in spreadsheets, diagrams or (my favorite) MindMaps.
        

        Who:
        Develop an Organizational Chart (if there isn’t one already).  Most companies will have some form of an organizational chart, this will be the foundation of this step.  Use Visio or a MindMapping tool to create or re-enter the parts of the organizational chart relevant to you, providing as many layers that you will be in contact with.  Include titles, contact information and any public relevant information.  Be careful about your notes, don’t get personal.
        

        What:
        Processes - Document what current processes are in place and gather all relevant documentation about them. Talk to as many people as meaningful about them, especially those utilizing them, to determine actual use and value.  You’re sure to get a lot of folklore thrown in.  Technology – Document and inventory all used and supported technology, get an understanding of any planned or potential changes in direction internally and from the technology vendors.  3rd Parties and Service Level Agreements – Get a solid understanding of all 3rd party vendors and relationships, including those for training.  Once again, work with as many people as possible and understand the short/long term agreements, historic working relationships, costs and SLA’s (service level agreements).  

      1.2.2 Processes for Knowing where you want to go
      

      • Typically the project manager is not involved in the business aspects of knowing where the company wants to go, however there are various strains of goal and scope brain storming that project management skills could greatly assist.  In recent times some formal processes have be implemented with some degrees of success, most notably Six Sigma which originated at Motorola (http://en.wikipedia.org/wiki/Six_Sigma).  The most valuable component of where you are heading is the idea or need aka the Goal. Project management processes could greatly help in the validation of the benefit of the idea and the scope/boundaries of change.  Many ideas are hatched, but few are truly evaluated and scoped to a degree they should be.
        

        The majority of New Ideas are not revolutionary thoughts, but additions to or improvements of existing products.  The most beneficial ideas are those based on adding or creating new products, improvements or corrections to existing ones tend not to provide the same overall financial benefit since they are often costs savings that are difficult to qualify.  There are many project management processes that help in the identification of the goal: For improvement projects – where the team is looking to improve upon existing tools and/or products you need to ensure that the groups is focused on the root cause issue and not a symptom.  Root Cause Analysis (RCA) is a set of steps in helping define the true problem that you’re looking to resolve (http://en.wikipedia.org/wiki/Root_cause_analysis).
        

      
      

      1.2.3 Processes for the planning to get you there
      

      • This is where 99.999% of all project management is currently done, getting you there (wherever there is).  While a very important aspect of the entire process, it tends to be the sole focus of project management and probably the root cause of why so many projects fail, basically the complete focus on getting somewhere…but I’ll cover my thoughts on this later. There are thousands of books, articles, discussion groups focused with this aspect of project management.  Holy wars continue to be fought over methodologies, public executions occur daily and entire generations of peers disparaged.  I’m a firm follower of the Agile Alliances’ Manifesto
        
        We are uncovering better ways of developing  software by doing it and helping others do it.  
        
        Through this work we have come to value:  
        
        Individuals and interactions over processes and tools  
        
        Working software over comprehensive documentation  
        
        Customer collaboration over contract negotiation  
        
        Responding to change over following a plan  
        
        That is, while there is value in the items on  the right, we value the items on the left more.  
        
        (http://www.agilemanifesto.org/)  
        
        When I first read it I knew I was delivered to a better place.  How much clearer and precise could it be? Unfortunately, the dream has yet to be realized through any unified approach.  

    1.3 Project Management Tools
    

    • 1.3.1 Tools to help you determine where you are
      

      • Knowing where you are is as difficult, if not significantly more difficult, then knowing where you want to go.  You would think that you know where you are, but most people and companies don’t, this is because to do so you  need to be very objective and willing to take a deep inflective look.
        

        Performing an inventory of processes, problems and organizational structure(s) would be a good start to understand where you are.   The most important aspect is the listing of current problems, these can be obtained from your clients, help desk, Sr. Management and team ‘discussions’.  Depending on what you company/your-team produces you might have many access points – or few – to reported problems.  Depending on your situation, it might help to develop a questionnaire (have it approved and reviewed prior to sending out) that you can send to internal and external people.  This information could be the input to a SWOT analysis Strengths/Weaknesses/Opportunities/Threats.
        

        Knowing where you are also means knowing what your strengths and capabilities are.  Is your company/team very good at delivering short high quality websites, do you provide exceptional customer support, do you have a deep understanding of a specific business vertical?  I’m a firm believer that by focusing on your strengths you will achieve more than working on your weak points.  If you’re a fish focus on swimming.  Make sure you capture this in your inventory/SWOT list.
        

        As far as actual tools to use, stick with Word (or OpenOffice) documents.  Most of the information you gather will be very business sensitive, information that you would not typically want easily available via a wiki or web based document.  A mindmapping tool would be good to use and highly recommended for all aspects of project management.

    
    
    • 1.3.2 Tools to help you know where you want to go
      

      • There are a few important tools to be used to determine where you/your-company/your-team wants to go.  I highly recommend a mindmapping tool to fully define and scope the project.  Understand the boundaries, the what’s-in/what’s-out list of items.  The list should utilize terminology meaningful to the group defining the project.  The confusion caused by the poor communication between the asker and the provider are probably the root cause for most project issues.  I need a burger – ok, here’s a burger – well where’s the fries WHERE ARE THE FRIES EVERYONE KNOWS ALL BURGERS COME WITH FRIES, gee – sorry that’ll be a change request.  Truly focus on communication early to ensure the correct scope is being captured, once again use: . mindmapping – to help gather the scope (aka Work Breakdown Structure – WBS) .cheap wireframes – I’ve found the only real use for PowerPoint is in easy/quick wireframe creation .role playing – if nothing else it’ll provide for some humor, capture it on video  Many times the place you want to be is where your competitors are, so it always helps to provide links to their site and/or information to your team to provide for a better understanding.
        

    • 1.3.3 Tools to help you plan to get there
      


• Chapter 2 - skills every project manager should have
  
  


• Chapter 3 - where project management is heading
  
  

Interesting discussion on which type of project manager you would hire..

Which Project Manager Would You Hire?

Posted by Pawel Brodzinski 

The cold hard facts about Quality

I’ve been involved in too many projects where quality is spoken about, tested for and held up high only to have it the first thing thrown out the door when delivery issues arise. It is often used as a reason for late delivery and a weapon to increase project costs. Let’s be upfront about a few things regarding quality:

• Its more than functionality of the application
  
• It’s much more then how the web page looks
  
• It should not be determined by a designer or QA person alone
  
• It’s not free OR cheap
  

Quality issues are always a symptom of the real problem, you can’t directly impact quality, but you can

• increase/decrease design time
  
• QA time/involvement
  
• sponsor/user interviews and involvement
  
• overall team quality (hire right, train and mentor) 
  
• ensure effective management (which impacts communication)
  

A good team is one that never discusses quality, because it’s a given that top quality will always be strived for.

Saying Thank You and Meaning Thank You

I tend to have a bad habit of saying what I mean and another one of often saying thank you…I’m not sure if it’s old age (I feel old), appreciation of things (thanks Joseph Campbell) an appreciation of the comedy of life (thanks Bill Murray)…or what…but I truly appreciate when people make a good effort in what every they are doing and especially when it’s related to something that I’ve asked them to do. If someone really wanted to know what I think of as being a good quality of mine, this would be one of them. What bothers me, as you might guess, are people who either show no appreciation for other’s efforts OR provide superficial supporting comments/actions based on some evil management course. As managers, leaders, peers – we need to begin to truly emphasize and realize the efforts of others if we are to achieve anything more then superficial success. Sermon over for the day.

Top 10 Reasons Why Corporate IT Sucks via doodlekit

via doodlekit

http://doodlekit.com/blog/entry/55860/top-10-reasons-why-corporate-it-sucks

don't forget to read the comments

When the bottleneck is you!

Busy, more work than time in the day? Having to spend more and more time prioritizing to make sure the most important items get the focus? Worried that any more work and you’ll be in complete overload? Sit back, put your feet up and think for a moment….are these signs that you’re creating your own problems, that you’re placing yourself in the way of progress for your team and have made yourself into a bottleneck of progress? NO – you say…can’t be…I’m the most important cog in this machine and that’s why I’m so busy...take an outer body trip and look at yourself and your team, could it be:

• Unwillingness to delegate (could be many reasons for this)
  
• Your need for involvement in EVERYTHING as a form of job security
  
• Inability to conclude/finish small/low-priority items to the level that they require (aka good enough)
  
• Analysis Paralysis? Basic lack of knowing when enough is enough and willingness to take a calculated chance?
  

In most cases you CAN NOT correct the issue of being overworked by working harder, you cannot correct it by getting help (unless you are truly over worked and are willing to effectively delegate) AND you cannot correct the issue by looking outside of yourself. Sit back, be VERY objective and try something new.

simply inspiring

What is an End Date?

We all throw dates around like they have no real value. Open your project management tool, enter a task or bug, description, assign it to someone, set the start date and end date. How much consideration is put into the end date? How often to you actually reach the end date with the intended (big word) delivery? If anything we push the end date out as far as possible (especially if you’ve been around for more than a few days) – so far we often see our clients and managers get nose bleeds – to ensure that they can be achieved. It’s tough to admit, but I’ve gotten to a point where I treat end dates pretty badly, a commitment to an end date is like a commitment to the bar tender that this is my last beer…or close to the last one. If we don’t believe in end dates OR have faith that they are nothing more than the latest date people will accept OR know that 90% of the time they’ll move for 100 reasons we can come up with quickly in front of a board meeting THEN why do we think that ANYONE else will ever have real value in them? Pulling dates from the air is easy, living up to what we commit to is a bit more. As project managers we need to start realizing that the majority of the issues and negative feedback we face daily are ones that we cause and initiate ourselves…no wonder a recent report pointed to project managers as being one of the main sources of project failures – we’ve forgotten how to speak the truth and stand by the commitments we make OR ensure that ones we received are followed up on.

Programming Languages are the root cause of our issues – at least most of our issues

Old firewood ovens have been replaced, refrigerators requiring large blocks of ice are now in museums and junk shops and old hand-churned approaches to mixing have been replaced a long time ago with the miracle of electricity….Progress is everywhere, Moore’s law speaks to hardware improvements….but what the heck happened to our programming languages? They’re frozen in time with no real significant change since the 1970’s (over 30 years ago)……how can you expect quality, performance and usability improvements when the basic building blocks are trapped in time when programmers were still living in caves? I’m sure you’re thinking about object oriented advances….well, hate to say it, for those few really using REAL object oriented coding, it hasn’t really solved much, basic bugging, recoding, lack of reuse, lack of patterns, lack of real error checking/trapping, lack of standards, lack of safety nets, etc. etc etc. are more prevalent than ever.

A telling sign that programming languages have not advanced much since the ‘70s is the continued high use of C – a pure, deep, solid – but OLD – programming language. (http://langpop.com/).

What we need is some real rethinking of how programming is done focusing on the current basic issues of buggy code, difficulty in deployment, team effort, etc…..I’ve seen a lot of people complaining, a lot of domain specific languages being created (which will add to the problem by having the same programming approach in various new domain specific languages) and NO real interest by any major IT organization or company in looking into establishing a new metaphor for programming….TIME TO WAKE UP AND DO SOMETHING……..

Your first date

The most difficult of all dates is the first one – speaking project related here….it could come and go without even a notice, which is unfortunate because it’s typically a good reflection of how the rest of the project will proceed. Did you hit the date? If so, did you make it with achieving the full intent of the delivery? Did anyone applaud? Was the associated task meaningful and the delivery justifiable to the effort of tracking it? Don’t put to little of a meaning on the first project date, it could easily determine the long term relation if you’re objective and open enough to appreciate it.