Training With Paper Airplanes

So I was in an Agile and Scrum Management class yesterday. 


Always looking for new best practices and efficiencies for what we are doing in software development. 


We did one exercise to compare the old Waterfall methodology with Agile. 


And the instructor had us as a team build paper airplanes one way and then the other so see the difference in output and outcome. 


Lo and behold, we had almost 40 planes in agile and only 6 in waterfall. 


What you see in the photo is the testing phase: we actually had to see if they could fly at least 10 feet without taking a nosedive.  😉


(Credit Photo: Andy Blumenthal)

Types of Project Management Office

This is a quick breakdown of the 3 types of Project Management Offices (PMOs).

  • Enabling (Supportive) — Provides best practices, templates, and tools “as needed,” and compliance is voluntary.
  • Delivery (Controlling) — Adopts framework or methodology, policy, and repeatable procedures, and a certain level of the standards are enforced.
  • Compliance (Directive) — Establishes strict standards, measures, and control over projects, and these are highly regulated.

A good place to start is with an enabling/supportive PMO and then progress to a more delivery/controlling model. Generally, a compliance/directive PMO is for more highly regulated organizations.


(Credit Graphic: Andy Blumenthal and concept via CIO Magazine and Gartner)

Lasting Decisions

So it’s a funny thing about decisions…


Decisions are supposed to represent the conclusion of a process involving the following steps:


– Research of the problem

– Decide on the scope

– Discover the requirements

– Determine viable alternatives

– Evaluate costs, benefits, and risks 

– Do some soul-searching

– And then resolve and commit on a way-ahead


While these steps are typically formalized in a work-setting, they may be done informally in our personal lives. 


But even after all this, we need to remain adaptive to changes in the environment that would cause us to reevaluate the decision and alter course. 

So a decision is a decision until we revisit the decision. 


The problem is that in some highly complex, unstable/turbulent environments, or ones where there are a lot of disagreements among stakeholders (such that there was perhaps not a consensus on the original decision to begin with) then “decisions” may be short-lived.


In this case, decisions may be half-baked, not even last until the ink is dried, and certainly not have a chance in hell to be executed on or seen through to determine whether they actually would’ve worked. 


In a way a decision that is so temporal is not even really a decision, but sticking your toe out to feel the temperature of the water, and any commitment of resources can and probably will be a complete throw-away.  


We’ve got to do the investment in the upfront work, really make a good data-driven (and inspired) decision, and give it an opportunity to blossom. 


Yes, we need to remain agile and change as we sincerely need to, but too much change and for the wrong reasons leads to going nowhere fast.  😉


(Source Photo: Andy Blumenthal)

What Are The Chances for IT Project Success?

So I was teaching a class in Enterprise Architecture and IT Governance this week. 


In one of the class exercises, one of the students presented something like this bell-shaped distribution curve in explaining a business case for an IT Project. 


The student took a nice business approach and utilized a bell-shaped curve distribution to explain to his executives the pros and cons of a project. 


Basically, depending on the projects success, the middle (1-2 standard deviations, between 68-95% chance), the project will yield a moderate level of efficiencies and cost-savings or not. 


Beyond that:


– To the left are the downside risks for significant losses–project failure, creating dysfunction, increased costs, and operational risks to the mission/business. 


– To the right is the upside potential for big gains–innovations, major process reengineering, automation gains, and competitive advantages. 


This curve is probably a fairly accurate representation based on the high IT project failure rate in most organizations (whether they want to admit it or not). 


I believe that with:

– More user-centric enterprise architecture planning on the front-end

– Better IT governance throughout

– Agile development and scrum management in execution 

that we can achieve ever higher project success rates along the big upside potential that comes with it!  


We still have a way to go to improve, but the bell-curve helps explains what organizations are most of the time getting from their investments. 😉


(Source Graphic: Adapted by Andy Blumenthal from here)

Project Suicide

This was sort of a funny scene in a project meeting. 


One person describing the challenges at one point, spontaneously and dramatically motions to take a knife and slit both wrists.


This absolutely got people’s attention.


Understanding the struggles the person was expressing, and trying to add a little lightheartedness to the situation, I say:


“This is a tough project, pass around the knife.”


This got a good hearty laugh around the table, with one person saying that this was the quote of the day. 


Anyway, we want to make operations as effortless as possible on people, but the project work to get there is definitely making people work for it. 


Let’s avoid project or people suicide–be supportive of each other, pace ourselves, team together, and problem-solve to get it successfully over the finish line.

 

Soon we can celebrate all the challenges we overcame together and from our determined efforts, all the wonderful results. 😉


(Source Photo: Andy Blumenthal)

Birthing An IT System

Managing IT projects is no easy task.


You’ve got to get the requirements right. 


Technical issues need to be resolved. 


Dependencies have to be lined up. 


Integrations need to work. 


Design should be user-friendly and intuitive. 


Change management takes real leadership. 


And so much more. 


A lot needs to go right for the project to be a success. 


While of course, just one or two bad apples in the project equation can quickly make for a failure if not controlled for. 


But you can’t let it…the show must go on, progress is waiting to be made, and the systems need to be delivered for the benefit of the organization. 


This is where real strength and determination by so many good people come in. 


Keep moving things forward–one step at a time–don’t stop!!!—another step and another–heave ho, heave, ho–until one day soon a beautiful and efficient IT system is born. 😉

(Source Photo: Andy Blumenthal)

Say YES!

Really liked this sign on my colleague’s desk.


It says:

Start With Yes


I remember an old boss who used to say:

Don’t make me get through no to get to yes. 


The idea as another colleague put it is to:

Keep a smile on your face and your focus on the customer; everything else takes care of itself. 


Basically, it’s all our jobs to make sure that the customer’s needs are being met. 


That doesn’t mean that we don’t need to differentiate between requirements and desirements or that we need to deliver the yacht in the first go around.


As a 4th colleague put it:

The customer is in the water. They want the yacht. But I can give them a boat. It gets them to where they want to go, and they no longer need to swim. We can work our way up to a yacht.


Good analogy analogy and good things to keep in mind for customer service excellence! 😉


(Source Photo: Andy Blumenthal)