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)

Don’t Just Sit There

Really liked this robot (Cubebot) in the store.

Love the colors and that you can change the pose in all different ways. 

This robot is pretty darn cute!

It’s funny in this sitting position though.

Just want to say: 

Don’t just sit there, do something!

Probably not that long before robots will be all over the place.

We’ll wish for just a little privacy from the darn things, just like from our 24/7 computer gadgets that we can’t let go of now.

Yes, we’re hopelessly dependent on the technology–it’s so helpful and we love it, but we can’t turn it off. 

They won’t be sitting for long. 

Robots–big and small, alone and in swarms, male and female, strong and intricate, smart and simple, worker and homemaker, doer and helper, companion and lover, where will it stop–it won’t. 😉

(Source Photo: Andy Blumenthal)

Agile Doesn’t Mean Endless

So Agile development is great for iteratively working closely with customers to develop and refine information systems that are useful to them and the organization.

But even in Agile, there is a beginning and an end to the sprint planning and project management.

Taking Agile to somehow mean endless in terms of adding more and more requirements or scope creep is not what is intended. 

Agile has to be bound by common sense somewhere between what is needed for a minimally viable product (MVP) and what is achievable with the designated resources, objective, and scope. 

Good project managers always have to be sound arbiters and be willing to ask the tough questions and determine if something is truly a requirement or simply a wish list item that is out of scope (but of course, could perhaps make it in for future enhancements).

We need to understand the difference between genuine customer service and irrational project exuberance based on inflated expectations. 

It’s not a dangerous project bubble we want to create that can and will get busted, but rather a successful project that is delivered for our customers that help them do their jobs better, faster, and cheaper.  😉

(Source Photo: Andy Blumenthal)

DMAIC Reengineering

A colleague gave a wonderful talk the other day on process engineering.

The key steps to reduce waste (Lean) or variation/defects (Six Sigma) are as follows:

Define – Scope the project.

Measure – Benchmark current processes.

Analyze – Develop to-be processes (with a prioritized list of improvements) and plan for implementation.

Improve – Executive process improvements.

Control – Monitor/refine new processes.

It was amazing to me how similar to enterprise architecture this is in terms of: defining your “current” and “future” states and creating a transition plan and executing it.

Also, really liked the Project Scoping questions:

– What problem do you want to solve/what process do you want to improve?

– Why do you need this?

– What is the benefit?  And to whom?

– What are your objectives for this effort?

– Who are the key stakeholders?

– When is this needed and why?

I think process improvement/engineering methodologies like this can be a huge benefit to our organizations, especially where the tagline is “Why should we change–we’ve always done it this way!” 😉

(Source Photo: Andy Blumenthal)