Phil Simon » Project Management

The World of No

philsimon — Thu, 10 Jun 2010 10:30:15 +0000

Without question, my least favorite word in the English language is usually “no.” I’d tell James Lipton as much if asked on the sometimes pretentious show Inside The Actors’ Studio. Now, there’s a reason that I qualify that statement with “usually.” In this post, I’ll tell you why not all “no’s” are created equal.

Appropriate No’s

Sometimes, no is the only legitimate response to a question. Consider the following:

It’s alright to steal music, right?
Are you going to miss Rush on this tour? (Hells no!)
Will you shoot par today?
Did you sleep past 5 am today?

These are examples of “appropriate no’s.” In each case, “no” is the only answer.

But alas, dear reader, there are other kinds of no’s.

Contemplative No’s

Let’s say that I propose a solution to a problem on a consulting gig that seems to make sense–at least to me. The decision maker listens to me and considers the idea. After careful thought, though, she decides against it and tells me why my idea won’t fly. She thanks me for the effort and appreciates my enthusiasm.

Contemplative no’s don’t bother me much. After all, I’m a consultant with no real authority. It’s their world; I’m just playing rent. They know what’s best. My advice is always theirs to take or leave.

Reflexive No’s

Again, let’s say that I’m trying to solve a problem. Maybe I’m trying to do something productive or try to make one of my partners, publishers, or clients money. Here are a few specific examples:

While working with one of my publishers, I have routinely proposed what I considered to be good ideas to promote our book. These include greater use of social media, book signings, other events, and book reviews.
When confronting an issue on a new system implementation, I’d figure out a “work-around” that would in no uncertain terms solve the problem.
Often I’ve dealt with wholly inefficient business processes and suggested reasonable alternatives to expedite things.

In each case, the decision maker didn’t bother to fully consider my ideas, often barely listening to my suggestions. The response was almost always something along the lines of “that’s not how we do things around here.” I call these “reflexive no’s” and I’ve come across them many times in my career.

And these bother me the most because those who give me “the reflexive no” just don’t try. They don’t care. They’re apathetic. They don’t want to learn or experiment. These people are stuck in their comfort zones and, as my friend Scott Berkun has written many times, this is exactly how mediocrity persists. That mentality stifles innovation and, ultimately, success.

Feedback

Am I just stubborn, cranky, and cantankerous? Does the reflexive no bother you as much as it does me?

The World of No is a post from: Phil Simon

Interview with William McKnight on Why New Systems Fail

philsimon — Wed, 21 Apr 2010 10:08:23 +0000

My friend and fellow author William McKnight has posted interview in which I discuss my first book, Why New Systems Fail.

Here’s an excerpt:

McKnight: Why did you title the book “Why New Systems Fail” when I think it really tells you how to succeed?
Simon: Thank you for saying that. I agree with you; I believe that the book is largely about making projects succeed. However, foolish is the person who refuses to recognize the abysmal success rate on IT projects and system implementations specifically.

I believe that the book’s title is short and descriptive. I tried to write a book that ultimately provides both general and specific advice for avoiding failure. Particularly in a recession, many organizations are going to get one bite at the apple. It’s important that they get projects right the first time.

To read the entire interview, click here.

Interview with William McKnight on Why New Systems Fail is a post from: Phil Simon

Technology Today #14: Andy Kaufman on The Dirty Little Secret in Business

philsimon — Tue, 09 Feb 2010 04:01:34 +0000

Regardless of your role in the software development and deployment life cycle, there are challenges and roadblocks that stand in your way. I personally find that technology challenges are typically not about technology. The often tend to be more about people.

Consider the following questions:

How do deal with difficult people who pose obstacles to your ability to deliver?
How do influence someone to act on your priorities even when you don’t have the organizational authority?
How do you find time to network when you’re overwhelmed with day-to-day work?

Public speaker and project management expert Andy Kaufman shares The Dirty Little Secret of Business. You won’t learn this secret in school, yet it is critical to your success. The secret is simple—it’s all about relationships. Andy describes the key relationships you must develop to advance your projects and career. Discover how understanding different personality types will improve your ability to build rapport, influence people, and control situations. Learn what networking is—and isn’t—and how to increase the effectiveness of your networks with less effort. Particularly in today’s challenging economy when you are being asked to deliver more—and perhaps are even worried about your job—it’s critical that you invest in the power of relationships.

In this podcast Andy refers to Dr. Robert Cialdini’s book Influence: The Psychology of Persuasion.

Some of Andy’s other podcasts can be accessed here.

To listen to the podcast, click here or visit iTunes.

Technology Today #14: Andy Kaufman on The Dirty Little Secret in Business is a post from: Phil Simon

Extremes in Risk Tolerance

philsimon — Thu, 28 Jan 2010 04:01:38 +0000

In my Getting to Know You post, the category for next blog topic receiving the second highest vote total was “IT Project Failure.”

Ask and ye shall receive.

I have been giving quite a bit of thought lately to the topic of enterprise risk management. In large part, this stems from the fact that I recently completed a project in which my client’s risk tolerance was off the charts. I mean crazy. In this post, I discuss three types of organizations with respect to risk tolerance:

The Zero Risk Organization
The Oblivious Organization
The Acceptable Risk Organization

The Zero Risk Organization

Several years ago, I worked on a project for an organization that would not do anything if there was even the smallest risk. To that end, it employed a full-time internal auditor to carefully monitor all IT projects. He would report his findings to the CIO.

So, you may ask. What’s wrong with this?

In the abstract, nothing. But IT projects are never abstract. Actions have consequences. The project consistently suffered as the implementation team attempted to address his concerns, and he had a bunch. Sure, many of them were well-founded, but how do you concurrently assuage an auditor’s concerns and make up time on a delayed project?

You don’t.

Simon Says

If your organization is not ready to take on some level of risk, then don’t start a major systems or IT initiative. Ever. All projects come with some degree of risk. It’s that simple.

The Oblivious Organization

Now, let’s turn to the other end of the spectrum. This type of organization is perhaps best epitomized by my most recent client. The mentality could be described as:

There was no such thing as risk. Period.

Here’s the crazy thing, though. The company routinely addressed IT projects in this manner. According to lifers, every system that the company implemented in the last ten years was managed the same way. Proceed as if nothing is wrong. Ever.

This was a shock to just about every consultant on the project. You see, good consultants have been trained to identify and attempt to minimize risks throughout projects. Sadly, the CIO did not want us “editorializing.” Translation: keep your mouths shut. We don’t like naysayers.

Simon Says

From a consultant’s perspective, you can’t win on projects like these. If you broach a legitimate issue, you’ll be silenced and possibly removed from the project. If you don’t, then you’ll invariably be asked, “Why didn’t you tell us about this?” Organizations like these have a high employee rejection rate; it takes a certain personality type of accept the risk of lawsuits, audits, and generally appearing foolish as you expose yourself and others to excessive levels of risk.

The Acceptable Risk Organization

Ah, I can’t tell you how much I enjoy working with companies and people who understand risk and possess a modicum of perspective. Serious risks are actually taken…seriously. Further, key people understand the time-sensitive nature of many problems. They understand that, as my friend Bob Charette has told me, risk is always a function of information, time, and money.

Simon Says

Of course, no organization has unlimited information, time, and money. Trade-offs need to be made. Fortunately, “acceptable risk organizations” understand this and are likely to make the right calls. Things won’t always go perfectly, but these realists create contingency plans in the event that things go awry.

Feedback

I have a few questions for you.

What’s your organization’s risk tolerance?
What causes some organizations to accept so much risk?
Can people with one risk tolerance be successful at organizations with vastly different risk tolerances?

Extremes in Risk Tolerance is a post from: Phil Simon

Mark McGwire, Project Management, and Coming Clean

philsimon — Wed, 13 Jan 2010 11:23:23 +0000

It’s hard to not hear about major events in today’s 24/7 news cycle, whether you want to or not. I can’t say that I’m a Paris Hilton fan but it’s really hard for me not to hear about her current adventures. By the same token, I doubt that even those indifferent to sports did not hear about Mark McGwire’s recent (if belated) admission that he took steroids during his halcyon home run hitting years.

The point of this post is not to excoriate McGwire for doing wrong. He was hardly the only guy to shoot up in baseball, much less all sports. Rather, I’d like to take a deeper look at his apology as it relates to project management and the corporate world.

McGwire’s apology was no doubt sincere but was equipped with an infuriating disclaimer. He did it “for health purposes.”

Huh?

For a transcript of the interview, click here.

Rant

Why don’t people just fess up when they are caught? I like to think that we live in a forgiving society. While coming clean is laudable, it’s hard for me to get over McGwire’s disclaimer. The whole thing me of a recent incident in which someone dropped the ball on an IT project and offered a similar excuse-laden apology.

To make a long story short, on the penultimate day of a consulting engagement, the project manager (PM) literally dropped ten custom report requests on my desk that I had requested several times over a three month span. Oh, did I mention that I was in the middle of another crisis at the time with production data?

The PM apologized but quickly added that “he knew that these reports were ad hoc, not ‘enterprise’ reports.”

Huh?

Don’t worry. I didn’t understand the distinction either.

Now, I have been writing reports out of enterprise systems for nearly fifteen years. There are all sorts of reports from all sorts of tools but dropping the ball is dropping the ball. Period. That’s it. Don’t try to bullshit me on this. (Incidentally, most of these were actually relatively easy reports to create but there was no way for the PM to have known this. In any event, to sit on important tasks for more than two months and then expect someone to save the day at the last minute represents a horrible work ethic for anyone, much less a PM who’s supposed to show leadership to the rest of the organization.)

Simon Says

When you screw up in baseball or the corporate world, just call a spade a spade. Equivocating merely increases the amount of damage that you’ve done to your credibility and reputation. I understand the need to save face. Really, I do. However, providing excuses only rubs salt in the wound and minimizes any benefit of the doubt that others will grant you.

Feeback?

What do you think? Do excuses irritate you as much?

If you enjoyed this post, feel free to subscribe to my RSS feed.

Mark McGwire, Project Management, and Coming Clean is a post from: Phil Simon

Can Consultants Lead? Three Viewpoints

philsimon — Fri, 04 Dec 2009 05:01:53 +0000

Management guru Peter Drucker once said, “Management is doing things right; leadership is doing the right things.” I’ve been thinking quite a bit about that line recently as I finish a, er, challenging project.

A few months back, I wrote a post called “Doing Things Right and Doing the Right Things” in which I lauded organizations that “got it.” From a consultant’s perspective, it’s simply a pleasure working with organizations whose management routinely does the following:

abides by best practices
listens to–and even encourages–dissenting opinions
holds itself accountable for unorthodox decisions
holds its end-users accountable for results
doesn’t pin everything on people like me

Well, I’ve entered Bizzarro World on my current project and it’s time to ask an important question:

Assuming that Drucker’s definition holds water, can consultants lead on difficult projects?

This post provides three viewpoints on that question.

Yes, we consultants can lead in the face of difficult clients, end-users, and senior management.

When clients routinely impose impediments to success and make suboptimal decisions, consultants can still do the right things. Ah, the case for optimism. Perhaps we do not (or cannot) tell our clients some of the things that we’re doing behind the scenes because we know how they’ll respond (not favorably). I suppose that “doing the right things” includes keeping clients in the dark about some of those right things.

For example, consider apathetic end-users who don’t look at data validation reports that manifest major issues. Consultants who proactively broach issues and encourage crusty end-users to investigate them are acting appropriately here, if perhaps above and beyond the traditional call of duty. Doing things like this is the very definition of leadership, especially when faced with a less-than-welcoming audience.

Is this paternalistic? Probably, but what’s the alternative? Diligent consultants are willing to risk both pissing people off and removal from engagements when their clients make bad decisions. After all, our names will be attached to the projects for better or worse and, in all likelihood, we’re going to be blamed for everything anyway. Why not go down fighting?

No, attempting to truly lead will only irritate clients and will ultimately “lead” to removal from engagements.

Many clients believe that no consultant is going to tell them how to run their candy store, to borrow a phrase from my friend Patricia Barlow of The Blue Mesa Group. Attempting to lead and influence the outcome of a project, engagement, or strategy is an exercise in futility. Add to the fray a bad economy and a related lack of consulting work. All of these factors make it ill-advised for consultants to truly exhibit leadership in these circumstances.

A corollary of this viewpoint is that some clients don’t pay consultants to lead. We are there to enable their vision, no matter how much we may disagree with it, no matter how certain we are that things will blow up when we leave. As a result, consultants need to “get over it” and allow clients to shoot themselves and reload.

It depends – the stock consultant answer to every question.

Not everything is a binary. Consultants may be able to lead to varying degrees based on the following factors:

the type of engagement (technology- vs. strategy-oriented)
the size of the engagement
the internal political climate of the organization
the economy (see above)
the industry
regulatory or audit considerations
timing

Two similar projects (much less two different ones) may yield vastly different opportunities for consultants to lead. A small scale data quality initiative at a nimble startup probably allows consultants to lead more than a large system implementation at a bureaucratic government agency.

Chime in, consultants, clients, and other thinkers out there. What do you think?

Can Consultants Lead? Three Viewpoints is a post from: Phil Simon

When Consultants Attack….Other Consultants

philsimon — Fri, 27 Nov 2009 05:01:30 +0000

Note that no alligators were harmed in the writing of this post.

My friend and fellow consultant/author Jim Harris and I have had a number of discussions over the past few week about our next blog bout. Our first one on

When Consultants Attack….Other Consultants is a post from: Phil Simon

In Defense of Consultants: A Punch-Out Based Rant

philsimon — Mon, 16 Nov 2009 04:30:20 +0000

One of my favorite games as a kid was Nintendo’s Punch Out. Yep, I grew up in the 80s when this game was all the rage. While I could never get to Mike Tyson, much less beat him, I was able to get pretty far.

Don Flamenco (pictured above) was one easy victim for even Nintendo neophytes. Just a simple left-right combination repeatedly would quickly knock him out. Hey, Don was no Von Kaiser.

I reference Don because, as a consultant, sometimes I feel like him. What’s more, I suspect that I’m not alone. Well, today I’m going to stand up for every consultant unjustifiably raked over the coals.

Now, I’m not completely naive, at least about these types of things. I’ve known for a long time about the blame game. One of the first things that I learned as a newbie consultant in 2000 is that (insert name of problem) is always my fault. I can document my concerns, write status reports until my fingers bleed, and copy the world on an email. However, after I leave a client site, I won’t be there to defend myself against the invariable quips that “he never told us that” or “well, that’s the way that Simon told us to do it.”

I also understand that sometimes organizations and senior managers want things the way the want them; no consultant is going to tell them how to run their business. A client once told a friend of mine (also a consultant) that “we don’t pay consultants to disagree with us.” Ouch.

While that mentality is troublesome, I’ve come to terms with it over the years. However, that is not to say that this doesn’t still bother me on occasion. So, to paraphrase from The Declaration of Independence, I hold the following four consulting truths to be self-evident.

Disclaimer #1

My intent here is not to bash all people and organizations that hire people like me. That would be pretty dumb, not to mention off-target. Many organizations are rife with senior management and end-users who allow consultants to truly do their jobs. For the purposes of this post, I’m only venting about clients who:

think that they always know best
routinely ignore consultants’ advice
make suboptimal–and irreversible–decisions
come back to those very consultants looking for blood

Disclaimer #2

I’m really not trying to whine here. I’m just blowing off some steam.

1. Most consultants generally know what they are talking about.

By “most consultants”, I mean experienced, battle-tested consulted warriors who have been in the trenches many times. I’m not talking about newly-minted college grads who are no doubt book smart but may lack the wounds and knowledge accumulated over years of battle.

2. If you don’t listen to your specific consultants because you don’t trust them, then get rid of them and find new ones. Good ones. Then proceed to listen to them.

This paradox never ceases to amaze me. Consider the following two queries.

What is the logic behind bringing in experts only to ignore them?
If they’re not experts, then why keep them?

These aren’t rhetorical questions. I seriously would like to know the answers to them. Feel free to comment or contact me.

3. Most consultants care about the success of their clients and their projects. They don’t disagree with their clients for giggles.

Look, the consultant’s world would be a far better place if we could all live in peace and harmony. I never met a consultant who preferred to work with difficult, apathetic, passive-aggressive, or change-resistant clients. Give me people eager to learn new technologies and make optimal decisions any day of the week and twice on Sunday.

When I feel the need to swim against the stream on a project, it’s not because I like increasing my blood pressure. Rather, I like to think that it’s because I care (see point #1) and I have been down a particular road before. Translation: I have the benefit of foresight that my clients probably don’t. No, I’m no psychic. However, in a year or so when I’m on another gig, clients may realize that I was right and certain bells cannot be unrung.

4. Clients who routinely ignore consultants’ advice must forfeit the right to blame said consultants forever.

Alright, this will never happen. Still, this is my modest proposal and I can be a bit idealistic (read: delusional) here. I for one would love to live in such a world, although I’m still working out the kinks in this one. If constitutional amendment isn’t passed, then I’d settle for the ability to say, “I told you so.”

In Defense of Consultants: A Punch-Out Based Rant is a post from: Phil Simon

The Chopping Block: Cutting Features from an IT Project

philsimon — Fri, 13 Nov 2009 07:00:09 +0000

I am often involved with projects that are running behind schedule and over budget. Such is life of an IT consultant, I suppose. In many instances, projects can recoup valuable time if non-essential features and functionality are removed from the immediate plan and postponed until a later time. This post explores the decision on what can and can’t be cut from IT projects.

Consider the following three questions:

What type of project is it?
Are executives’ incentives aligned with those of the organization?
What are the risks and rewards of keeping non-essential functionality to the overall project and the organization itself?

What type of project is it?

Consider two types of projects:

Those that involve a Waterfall or more sequential methodology.
Those that involve Agile methods.

Waterfall Projects

Clients are typically reluctant to cut functionality from Waterfall-based projects for one simple reason: there’s typically (and mistakenly) a “now or never” mentality. In other words, key stakeholders believe that if the software isn’t present immediately, they’ll never see it.

This may or may not be the case. Delays, budget cuts, internal politics, and key employee turnover often mean that the best intentions regarding future roll-outs are derailed. I’d argue, however, that continuing down a parlous path because you’re afraid that internal obstacles will prevent you later on is a fundamental misstep.

Agile Projects

On Agile projects, internal players tend to understand the concept of phases better. They are more likely to sacrifice “nice to have” functionality if it’s likely to increase organizational risk. Project teams, developers, and senior management know that the next version of the software (or the next phase of the project) can easily incorporate enhancements. There’s no “burning plank” mentality here: there will be a next version, and typically soon.

Simon says: Determine in advance which features are essential. If necessary, be prepared to drop non-essential features for the overall good of the project.

Are executives’ incentives aligned with those of the organization?

To borrow a phrase from poker, executives sometimes go “all in” with a particular feature, application, module, or system, refusing to ignore signs of peril. For example, a few years ago I worked on a project in danger of imploding. System testing and data validation were months behind schedule, affecting the entire organization’s financial health, not to mention little things like payroll and financial reporting. Less important, the roll out of a manager self-service application that would minimize paperwork also looked doubtful, although this affected a very small percentage of employees in the organization.

While the overall project suffered, CXOs refused to cut self-service from the project plan. Why? Because their bonuses were tied to the introduction of the tool, whether it was successful or not. This is a classic example of senior managers letting their provincial self-interests override their responsibilities to the organization at large.

Simon says: From day one, make sure that senior managers’ incentives align with those of the organization.

What are the risks and rewards of keeping non-essential functionality to the overall project and the organization itself?

Consider an ambitious CRM project. Everyone would love to have sexy analytics (now that would be a great title for a book) from day one. However, does that functionality come at the risk of not being able to enter new customer sales? The latter is pretty important, even though it’s not what sold senior management on the CRM app in the first place. Those dashboards aren’t worth a red cent if they don’t contain accurate data. Imagine the chaos if basic sales data cannot be obtained? Will fulfillment become an utter nightmare? Will the data become corrupt and impure, requiring a massive data cleanup effort?

Simon says: Remember that there’s always tomorrow. Absent some really compelling business need, ensure that critical functionality is rock solid before chasing next generation functionality.

Conclusion

Most people realize that IT projects are rarely perfect. If behind on a key project, don’t hold out for each and every bell and whistle promised from the beginning. Consider dropping non-essential features for the good of the project and the organization.

The Chopping Block: Cutting Features from an IT Project is a post from: Phil Simon

Project Management Lessons from Rush

philsimon — Tue, 10 Nov 2009 04:51:40 +0000

I am not a terribly balanced person. The term “moderation” is a little unfamiliar to me. My friends know this about me and, of course, needle me incessantly about many of my foibles. Don’t worry about me. I can take it.

Perhaps the biggest target on my back over the last twenty or so years has been my unadulterated love of Rush, the Canadian power trio criminally not elected to the Rock and Roll Hall of Fame. (Don’t get me started on this one… I mean, come on, over 30 million albums sold!)

Anyhow, I doubt that many of you would care to read about a post about Rush in and of itself. Fortunately, I can relate the band’s lyrics to many aspects of everyday life–or at least my everyday life. And my life involves IT projects.

Can someone say “segue?”

Disclaimer

As much as I love Rush, I’m not silly enough to think that the band’s virtuoso drummer and lyrical genius Neil Peart ever penned even one song directly about project management, GUIs, databases, and organizational change. While Rush has addressed technology in songs such as Virtuality and Digital Man, the band has tended to write about matters more existential, visceral, cerebral, political, and social in nature. Fortunately, Peart’s lyrics are profound enough to allow for multiple interpretations, especially by an obsessive-compulsive Rush fan.

Without further ado, here are my top four Rush lyrics relevant to IT projects.

Far Cry

Album: Snakes and Arrows

Lyrics:

It’s a far cry from the world we thought we’d inherit

It’s a far cry from the way we thought we’d share it

You can almost feel the current flowing

You can almost see the circuits blowing

We’ve all been here before. Enthusiasm at the beginning of the project gradually erodes from the get-go into either skepticism or outright negativity. The usual suspects include: delays, internal politics, squabbles with vendors and consultants, general infighting, and budget overruns.

By the time that project has reached its anticlimactic denouement, the ultimate result is usually a suboptimal implementation and final product. Stakeholders lament the current state of a project with so much initial promise.

Hemispheres

Album: Hemispheres

Lyrics:

We can walk our road together

If our goals are all the same

We can run alone and free

If we pursue a different aim

Ah, the differing agendas of each faction. The goals of client senior management, IT, business users, consulting firms, and software vendors are often anything but aligned. Many have written before about Agency Theory and the tendency of each party (and person) to work in its own self-interest. Perhaps this is best exemplified in the popular book Freakonomics. The simple point is that everyone rowing in the same direction tends to produce a smoother and overall better project. For many reasons, however, this is rarely the case.

Tom Sawyer

Album: Moving Pictures

Lyrics:

He knows changes aren’t permanent,

But change is.

Rush’s signature song continues to evoke powerful images through its nebulous lyrics. The challenge with all things technology is that nothing is static. Business needs change frequently these days, forcing organizations to evaluate whether their current technologies have become outdated. The term “legacy system” does not merely refer to a quarter century mainframe clunker stored in a dark IT closet, spitting out punch cards and emitting weird noises throughout the night. Even “it company” Twitter had to blow away its initial IT infrastructure after its management realized that its popularity had quickly exceeded the capabilities of Ruby on Rails.

Change is permanent.

Roll the Bones

Album: Roll the Bones

Lyrics:

Well, you can stake that claim

Good work is the key to good fortune

Winners take that praise

Losers seldom take that blame

If they don’t take that game

And sometimes the winner takes nothing

We draw our own designs

But fortune has to make that frame

Let’s be honest here. The best project manager, CIO, or consultant cannot possibly predict with any degree of certainly all of the forthcoming challenges of a major IT endeavor, much less the time required to resolve them. Sometimes an innocuous question results in the discovery—and resolution—of a problem that would have otherwise gone unrecognized. Yes, hard work matters. Project plans, testing, and the like are all important. However, try as we might to be all scientific about things, luck is huge. It ain’t all skill.

I’m sure that I’m missing some lyrics. Rush fans of the world unite! What other lyrics apply to the IT world?

Project Management Lessons from Rush is a post from: Phil Simon