click here to hire
Michael Mah for your next speaking engagement >
How did you get into the software management
field?
Kind of by accident, actually. I studied electrical engineering
and physics at Tufts University – I didn’t listen
to my father who was a Wall Street trader in the 1970’s.
He wanted me to be an attorney in Wall Street finance. I said
I didn’t want to work in a field characterized by the word
chaos (laughing).
The irony is that many of my clients in IT
have been large multinational financial services firms on Wall
Street. I once looked at the sky long after my father had passed
away and said, "I know you’re chuckling ... and I do
remember our conversation about this."
Initially, I was drawn to aerospace as a starry-eyed
kid watching Apollo space launches in the 60s. One of my favorite
places is the Rose Center for Space and the Hayden Planetarium
in New York City. Go visit it – it will inspire you.
After finishing at Tufts I worked on the nuclear
submarine program in the early 1980s, managing software test engineering
at Sperry Corporation for the Trident II navigation system. Working
on submarine testing would also enable me to spend time in Cape
Canaveral FL. I could watch shuttle space launches from the deck
of our test ship.
What do you remember about your early
mentors?
A vice president named Alan Markow put me on a fast track by assigning
me as Group Leader for integration testing. Trident II submarine
navigation was a $750 million dollar project that involved weekly
briefings to the U.S. Navy command in Washington DC. I was pretty
young to be in that position, but he told me that it would be
good for my career. I was a sucker for that kind of talk.
Little did I know that others didn’t
take the job, because more experienced engineers wouldn’t
touch it with a ten-foot pole. You were supposed to resolve all
these conflicts before and during testing with this monster deadline
looming; trying to gain the cooperation of people in different
departments who you didn’t control. The submarine program
was like "Top Gun". I had to report progress to a Navy
captain in Washington DC every week, getting on the NY to DC shuttle.
It was high-intensity to say the least.
But working on the nuclear submarine
program must have been fascinating.
It really was. The job of the navigation subsystem was to "fly
a submarine blind", windowless, through vast dark undersea
valleys, canyons, and mountain ranges where the vessel is the
length of a football field. Remember the movie, "The Hunt
for Red October?"
Submarine navigation is a complex system of
six mainframe processors all communicating as one, each commanding
a major subsystem - inertial gyroscopes, velocity measuring sonars,
gravity sensors, satellite communications. It steers a submarine
the size of a football field through undersea mazes. A wrong turn
could be catastrophic. It’s an amazing feat of technology
and was an incredible job to have as a young engineer.
But you had to believe in the deterrence theory
to work on it. Some felt that deterrence was credited with keeping
the world safe from major conflict for over 50 years after World
War II. Not many people know this, but in terms of firepower,
a single ballistic-missile nuclear submarine is the most powerful
entity on earth, after the U.S. and the former USSR. At the time,
the theory held that no one would threaten world peace because
of nuclear deterrence. Today the world is quite different.
How did you first come across Larry Putnam’s
work on software metrics and project estimation?
The navigation software on Trident II was one of the most complex
systems ever created by many brilliant scientists. But the project
fell behind schedule and was a bit lost at sea, to use a metaphor.
There was a deadline, and it wasn’t certain if we’d
make it. Defects were rising, and had yet to nose over and head
downward. Software releases for at-sea testing were slipping while
the deadline remained fixed.
In the grand scheme of things, this taught
me that deadlines really can be misleading. Sometimes they’re
somewhat absurd, to be truthful about it.
Larry’s work is brilliant. Not many people know this, but
his background is in nuclear physics and statistics, and he discovered
fundamental software behavior "laws of nature" by studying
thousands of completed projects. These laws hold to this day.
No one else had the credentials to do this right, despite their
claims. Many haven't published their research for peer review
the way he did either. They may have written a few books, but
they left out the math because there was none, just simple division
on productivity.
The predictive algorithms in the software
lifecycle model that Larry published were like a crystal ball.
Calibrating the estimating model (now known as SLIM-Estimate),
we found that we could predict both the timeline and the defect
rates on the Trident software to better than 90% accuracy. Risk
and contingency planning would easily take us to the remaining
10% we needed.
That kind of accuracy may be possible
for aerospace projects. But does it work on other classes of work
like IT, banking/finance, or systems software?
Absolutely – because of an open algorithm architecture,
you can calibrate the model using a company’s own projects,
or using statistics from the QSM industry database.
So in the last 15 years of my consulting work,
I’ve worked with scores of companies and applied it successfully
on projects like space shuttle engine controllers, aircraft navigation,
scientific and systems software, medical systems, business IT
processing, and Wall Street trading applications. Couldn’t
resist the last category.
Did any other approaches that you researched
achieve the same level of accuracy?
Not really. Other methods I looked at had major shortcomings.
By not being open by design, they were stuck in a locked world.
Some emphasized a singular approach to measuring software size.
It’s more complicated than that. Other methods marketed
themselves as sophisticated, but I struggled with the fact that
their algorithms weren’t published in the public domain
like Putnam’s. Most didn’t allow you to reliably explore
project trade-offs. They led you to believe that there was only
"one" answer for a project. We know that’s not
true.
Also, when some of these models were scrutinized,
I found 8th grade-level linear math. I could smell this a mile
away since non-linear math is all you do in engineering –
that’s how the universe works. Since software projects don’t
behave linearly, these were a bad fit. It’s a shame, but
someone once said that a lot of people fall easily for linear
approaches that work poorly, rather than use non-linear approaches
that work well. It’s true.
For example, according to Fred Brooks of IBM,
putting twice the people on a project doesn’t cut the schedule
in half, but some of these methods allowed you to do this. And
people try it all the time and fail. These methods also didn’t
address the fact that defects would rise dramatically if you ramped
up aggressively on staff.
By the way, we’re seeing this high ramp-up
on offshore outsourcing projects since labor is cheap. Guess what
happens to defects?
How did you get into the field of negotiation?
Tim Lister (author of Peopleware and Waltzing With Bears, with
Tom DeMarco) is a longtime friend. I was frustrated that all the
advanced software metrics and estimation research alone wasn’t
solving the problem of industry conflict and failed projects.
Also, two of my largest clients were on the verge of suing each
other to death because of a huge contract dispute on a multi-billion
dollar outsourcing deal. I was trying to help mediate it.
I asked Tim about this because I knew he was
also a professional arbitrator, in addition to being a software
expert. He said, "You should check out the work at Harvard.
They have something called the Program on Negotiation at the Law
School. It’s a three-way collaboration with MIT and Tufts."
So I spent a year studying dispute resolution
and mediation there. Needless to say, I got religion.
How could the work there help the software
industry?
Well, a recent study by Cutter Consortium showed that conflict
is epidemic in the software and IT field. Everyone’s racing
at Internet speed. It’s estimated that the average software
organization has about 50 disputes in litigation. Some are in
the tens or hundreds of millions of dollars.
The father of modern negotiation, Roger Fisher,
is professor emeritus at Harvard Law School. As a young man, his
exposure to conflict was during WWII serving in the U.S. Army
Air Force, and in Paris with the Marshall Plan. When he returned
from service, he found - like many other young veterans - that
many of his boyhood friends and classmates were killed in battle.
Since then he’s dedicated his life to solving conflict.
Years of research by Professor Fisher and
others at the Harvard Conflict Management Group (CMG) and at PON
brought forth new methods - most of which are being applied at
the international level - on the world’s toughest conflicts.
There’s even an initiative entitled "The Project on
Preventing War". These methods are now making their way into
the corporate world for the rest of us. It’s a trickle down
effect. I feel this research also holds the answer to the conflict
that’s afflicting the IT industry.
That’s the big picture, but what
about for a manager in an IT organization? How does this work
apply to them?
The typical IT manager is in a vice. She’s given all these
Internet-speed deadlines, forced into a constrained budget (especially
in recent years), with ever increasing demands for more functionality
by client organizations. It’s the "Perfect Storm"
for conflict.
At the same time, IT managers were never trained
in conflict and negotiation. Some of us were drawn to technology
for the pure science and research aspects. Many engineers and
scientists chose their fields because it wasn’t people intensive.
There used to be lots of jokes about engineers’ people skills
at Tufts and in the companies I worked in.
And yet, today’s world demands that
we interact with more people than you can imagine. Constant negotiations
and difficult conversations among IT executives, development teams,
clients, VPs, and CIOs. Commercial and deadline pressures sometimes
demand outsourcing. So now you’ve got potential disputes
between companies, on top of the tension inside a company. And
some of these companies are offshore. Voila, now you’ve
got international relationships. Who knows how to handle those
well?
In my experience, unresolved conflict can
rip apart an organization and its relationships from the inside-out,
and render it ineffective, mired in the energy sapping distraction
of infighting. We can’t afford that in today’s commercial
marketplace. Everyone loses. We need to win.
Why is software and IT so important to
today’s organizations?
One common thread I’ve found is that software and information
technology is highly strategic in every company I’ve worked
with. We have to get it right if we’re going to be successful.
In my opinion, some of the cuts during the recent recession were
overdone, and more than a few companies are now paying the price.
Fred Smith, the CEO of FedEx, once said that
planes and trucks were commodities. They became a sensation by
using back office IT that made overnight delivery possible, which
was the new product built out of the commodities. They blew everyone
away.
Then others caught up and overnight delivery
became a commodity. Smith now says that it’s not overnight
delivery that’s the product - the product is now the information
about the delivery! So now front office IT is leading the way,
and FedEx is still winning because of their IT. Lotta smart people
in Memphis.
Jeff Bezos from Amazon recently said, "By
building new technology ourselves, we get to offer a better customer
experience. Does that give us an advantage? Absolutely. Now, if
we just rest on our laurels, we’re not going to enjoy that
advantage. You have to continue to innovate."
A lot of IT people are amazing: So many have
the most tenacious work ethic, a "never say die" willingness
to solve problems. That’s part of the problem – we
overpromise. I struggle with it sometimes too; just ask my wife.
What are some of the innovations in software
management science?
Today there are new capabilities and software management technologies
that we’ve never seen before. We can measure and predict
software projects "in-flight" – to better than
90 percent accuracy, very early on. It’s a lot easier to
benchmark historical performance against industry trends today
– we’ve pruned out practices that didn’t work
as well.
It’s easier to manage the implementation
of software packages, selecting software vendors on competitive
bids and manage outsourced relationships. The list goes on.
But there’s one thing to note: Tom DeMarco
was right when he said, "IT is change. It consists of so
much more than writing and testing code. The real and always difficult
challenge of IT is to transform the organization. A new program
or system is merely a vehicle for this. The hard part is not getting
the software to work but rather getting agreement on it before
the fact and effecting the necessary changes to the company and
its procedures afterward."
That’s where modern negotiation science
fits in.
What’s the upside? What’s
your vision for how it could be?
Imagine having accurate and reliable information on your most
challenging IT projects. Knowing with good certainty what is likely
to happen with the schedule on your next project. Having dependable
historical knowledge on the how projects behaved in the recent
past, to better predict future outcomes. Knowing the accurate
"location" of current projects that are "in-flight".
Now imagine having at your disposal, all the
tools and skills you’d need to solve interpersonal conflict
on both the individual and organizational levels. A rich resource
of negotiation and mediation skills. The ability to overcome and
navigate through the unfair use of leverage being wielded by tough
adversaries. Being able to manage difficult business conversations
and uncomfortable relationships with better ease.
Blending software measurement and estimation
science with modern conflict management techniques presents untold
potential for today’s modern organization. This is but one
possible future that I envision from my time in this field over
the last two decades. I like to imagine a future that holds remarkable
potential using the far reaching advances in technology - made
possible by efficiencies from skillful use of modern negotiation
and relationship management. We could create the best of all possible
outcomes in whatever work we choose to do in this lifetime. That’s
what the Agile Executive can do.
click here
to hire Michael Mah for your next speaking engagement >
Contact QSM Associates to inquire about schedule
availability: info@qsma.com
or (413) 499-0988.
Read Michael’s
CV >
What others have said about Michael
Mah’s Speaking Engagements:
"People say I’m
a guru in the software development industry. Well, my guru is
Michael Mah!" – Tom Demarco, Principle
Member, Atlantic Systems Guild, co-author of "Waltzing with
Bears – Managing Risk on Software Projects," 2003 Jolt
Award Winner
"The SM/ASM Conference
would do well to model Michael’s class. He is superb!!!"
– Pam Phillips, QA Manager, Washington Mutual Bank
"Excellent quality
of instructor and instruction. Michael made the course fun and
interesting." – Jim Felty, IBM Rational
"Best speaker I’ve
seen at conference by far." – ASM/SM
2001
