And the really great thing about Prinergy is that if you have one, you don’t have to worry about document management. Well, you have to worry a little, but it’s an order of magnitude less worry than having just a bunch of files dumped on a server.

I spent this morning in a wrap-up meeting with one of my clients, a VP in a mid-sized company, going over the report I had written on their internal print centre. We got to that point in the meeting where it was, yeah, you’ve got pages and pages of stuff on the print centre and pages of recommendations, but what is the one thing we should do?

So I said well, the print centre keeps all its business forms on a file server in the closet. Yes, it’s backed up but that doesn’t make it a system. Like if the print centre manager leaves tomorrow who is going to find all that stuff for reprints? Go buy a Prinergy system (They said they would think about it. They always do. It’s not a crisis yet.)

And don’t think that this company is the only one out there who has this problem, at least in Vancouver. A few years ago I was chatting with another guy who knew the IT scene pretty well and with regard to internal business documents, isolated islands of manual numbered documents rule.

I wonder if most offset printers realize how damn lucky they are that Prinergy has an Oracle database under the hood. Again, I can only speak of the scene in Vancouver, but there are lot of companies around here who are playing loosey-goosey with their documents, meaning if the right people leave at the wrong time, then they are in a world of trouble.

Don’t get me wrong, I’m not complaining. That’s how us contractors put bread on the table. We wait in the shadows like vultures, and when chaos come we feast on the remains of the battlefield!! Heh, heh, heh…

One well-known factoid in project management world is that 74% of all IT projects finish behind schedule. You know, I would have thought the number would have been higher.

When I worked in the software development group at Creo, I don’t think any of my projects ever finished on time (except for one), but pretty well all of them finished under budget. Actually, I don’t think I ever had a real budget for most of them. I was given a few guys and told to go do something. Then one day, I was project-managing about 10 guys sprinkled over three different teams (Note: PMing people is different than managing people. What I should say, is that one day I found myself trying to get about 10 people to do something. Which is different than being their functional manager. If you are a functional manager, you get to just tell your people to do something, and they better do it or their butts are in a sling).

Anyways, it’s no big trick to get a project completed on time, you either add more resources or de-scope some features. But note that in case one, you are spending more money, and in case two, you are going to disappoint some stakeholder. In my personal experience, it’s pretty rare to find a collection of senior management types who are willing to shell out more bucks just to meet some arbitrary calendar date. Oh sure, there are some projects which have very good reasons as to why they need to be completed by a certain date (for example, the Olympics) but it’s amazing how often a date is set just because… a project needs a end date. Whatever.

I did have one project that could not be late because the components were to be replacement for some OEM code and the contract to use that code was going to expire. Senior managment had made it know that they would rather crawl over broken glass rather than renegotiate the OEM contract. Surprise, surprise, beta ended two weeks before the expiration of the contract. When a PM has executive blessing to veto all and any scope changes, it’s amazing how everybody can adhere to the timetable.

The PMI guys have a nifty name for what is also called feature creep in the software development world: “Gold-plating.” This is term for a feature that is added on during the development cycle that wasn’t in the original project charter or project plan. Happens all the bleepin’ time. It’s very bad to allow “gold-plating” in a project, according to PMI.

So naturally, I allowed in pretty well all my projects (they made a PM at Creo before I could read the PMI stuff). To be more specific, if a request came in from the field for a feature or feature enhancement, I would take it to the developers to see how long implementing that feature would add to the schedule. On first meeting, I would usually get the brush-off. Then I would let the matter wait for about 3 days or a week. Then I would follow up. If it wasn’t too hard to implement, then we would try to do it. Naturally, the project would be a little late, but if I got happy points from the field, than who cared about deadlines?

Mind you, most of my projects were weeks late or maybe a few months. Proejcts that are massively late are usually either very high-risk projects where everybody is waiting around for some genius to design the crucial anti-gravity components or “drifty” projects that have poor management. Actually, when I say “poor” management I mean managers who are too chicken to kill a project that deserves killin’ because they are scared to lose their jobs. So they keep the projects goin’ and goin’ and hope that senior management doesn’t notice that the project that was suppose to take six months is now into year three.

Show me an experienced PM who has never taken an active part in slaying a project, and I’ll show you a bad PM.

Right up front, you have to decide which approach is going to provide better QA for your product: Environmental mimicry or egression testing. The choice you make will dictate the people you hire: Subject matter experts (SME) or scripters. And need I bother saying that each choice has its advantages and drawbacks over the others?

Most everybody knows about the importance of regression testing, and why you need a scripter. If you don’t, a scripter is somebody who can write scripts that automate the testing. Because if you don’t have automated batch tests, then by the time that version 62 of the software rolls around, the test team is just going to focus on testing the new features, and absolutely nobody is going to want to open up the program, click on “save file”, and type in “foobar” and hit okay for the 63rd time, and that means regression bugs will creep and not get caught. Some tasks just have to be automated or they won’t get done.

But you also need SMEs for environment mimicry, or rather to build a test environment that hopefully shares many similarities with the real world. For example, let’s say you have a software application that reads in a PDF file and prints it out to a color plotter. You may need a color SME to calibrate the plotter and plug in the proper ICC profile so that if the plot comes out looking terrible, you will be able to determine if it’s the app that is causing the problem or something else.

If you are building a version one of an application, then your tester is probably a SME, a industry expert who works with the developer team in building the test environment, generating test cases, and acting as a sounding board when discussing feature requests. Important note: Discussing features and their implementation is the most fun part of a job for a SME, whereas the first two responsibilities can oftentimes be tedious and annoying. So you need to stay on the SME to make sure they understand that’s their job to make sure the plotter has paper loaded, and yes, they need to fill out ALL fields in a test case report.

A good SME is a Godsend, not only acting as eyes and ears for the developers, but also for the product & project managers. A bad SME can make your life a trip into purgatory that lasts well past the completion date of the project. It’s most important to hire a SME with really good oral and written communication skills: Somebody who can sling the paperwork and talk to developers is worth their weight in gold. If you are building a version one application, the absolute worst choice you can make is to hire a junior engineer or programmer and have them learn on the job. If the enraged customer base don’t tear the poor guy from limb to limb at the first opportunity, then the sales force will pummel the guy senseless at the first trade show. The best SMEs have a reasonable amount of street experience, very good communication skills, and a pretty thick skin. The relationship between your head developer and the SME is key indicator of how well the project is going: If the two are buddy-buddy and give each other excellent grades on their performance reviews, then all is well with the world. If the two can’t stand each other guts, then you should be spending a lot of time pacing the bedroom floor at night, losing sleep (and also looking over resumes so you can replace your SME).

Sadly, a development team tends to lose SMEs over time. Usually, as soon as a project is launched, the SME’s time is usually taken up dealing with the documentation team, customer support staff, demonstrators, and the sales force. Over the long term, a software development culture where the code-writers are king and everybody else is a second-class citizen, tends to grate on a SME. They either go native (learn to write code themselves) move up into management (like yours truly) or move over to technical sales (where the money is better).

Scripters start to make their appearance near the end of a project, or if the application is a version two or higher. If you have inherited a team with scripters, then you have been blessed, as they are one of the signs of a mature and competent development group (daily builds and proper source controls are other signs). In a perfect world, you would have your SME feed test cases to the scripter who then builds an automated suite that can take the app through sanity checks on a daily basis. However, for this to happen you need a lot of things to fall into place: 1) A scripter who listens well 2) A SME who communicates well and does not feel threatened by the scripter and the automated tests 3) Developers who respect the progress and don’t break the automated test suite with gratuitous radical changes to the application.

On most projects, this level of sophistication in building a test environment doesn’t occur because of logistical constraints. However, if you are hoping the application that you are building is one that will last for a decade, it’s crucial to the maintainability of the code base that you build a strong test infrastructure. Without a good SME, you’ll have no eyes and eventually get brain damage from running into walls all the time. Without a good scripter, you’ll give up running your sanity tests over the long term, and eventually your application will collapse under the weight of unfixable regression bugs.

So I picked up yet another book on software development and started reading. I wasn’t able to finish it because it’s giving me such a headache. Every few pages I get the irresistible urge to slap my forehead. At this rate, I’m going to get a concussion by chapter three.

Anyways, this guy goes on about requirements: How not having proper requirements causes projects to be over budget and behind schedule, how feature creep leads to unmanageable project schedule and demoralized developers, yadda, yadda, yadda. No, really?

And his prescription is that somebody write out the requirements and get all the stakeholders to sign off on them. Of course, there is not just one kind of requirement - noooooo! - there are many kind of requirements. As well as user requirements, there are business requirements and design requirement and thingajig requirements and …. I don’t know, but lots of lots of funky requirements and gosh, if the project manager gets all the requirements written up and signed off by all the stakeholders, then hallelujah, this will be the ONE project that will finish on-time and on-budget. If only those stupid project managers could write up a good set of requirement documents….thump!

Sorry, that was my head hitting the desk. I think I lost consciousness for a few seconds.

Okay, let’s try to refute this viewpoint which seems to be conventional wisdom with the one exception where iron-clad written requirements are the rule: Embedded systems. Basically, it’s really hard to change a chip after it’s been designed. Duh.

For pretty much all other software development work, it’s a good idea to write down a set of preliminary requirements. And then print them out. But print them out on very soft paper that can be used in the smallest room of the house. Because in a very short period of time, that’s the only room where that piece of paper is going to be useful.

There are two main reasons why, one obvious & one subtle. I’ll start with the obvious: Let’s pretend you are the customer. You have signed a contract with a software development house to build a nifty program that does something. You have agreed to pay money. In most cases, you are paying a lot of money. You have put your signature on a piece of paper for something that doesn’t exist in the present. You are also painfully aware that when this piece of software is created, if it’s does not meet the expectations of your stakeholders, they are going to let you know about it. And how times does a software release meet 100% of the customer’s expectations?

Now, after signing a piece of paper for what many in your organization consider an obscene amount of money, a certain period of time elapses and you get another piece of paper to read, with a title stating it’s a design/user case/business/whatever requirements document. You read through the document. It looks okay. There’s a space for your signature. Maybe you sign it. Maybe you send back an e-mail saying you signed a piece of paper for umpteenth millions of dollars, and that’s the only piece of paper need to sign, ever. But let’s pretend you sign off on the requirements doc. Does this mean that you, the customer, have given up the right to ever contact, communicate or nag the development team with new features and/or requirements?

No. Never. Ever. There is no customer that has ever existed since the beginning of time that will not continually pester the development for new features right up to the moment of release and after. Get. Used. To. It.

So the lesson for any project manager is not spend too much time on drafting requirement docs. Sure, bang them out quickly, and I mean bang them out, but if, miracles of miracles, the customer sends back an okay and a signed-off document, don’t even think your job is finished. The fun has just started.

This brings up my second point about falling into the documenting-requirements trap: getting all the requirements is super-hard. In most cases, it’s impossible. Not even the customer, and the customer of the customer, can give you 100% of the requirements.

Look, it’s like going to Julia Roberts fan club and saying: “We want to make a love story with Julia and Brad Pitt. They fall in love, they fight & break-up, and then they make up and fall in love again. At the end of the movie, everybody in the audience because the movie was so wonderful. Here is the script of the movie. Can you assure us that after seeing this movie, you’ll reach for your hankie?”

Let me recount an example from the real world (I have changed some of the details to protect the innocent): One of Creo’s customer had some printing technology that was running with a software suite developed in the early 1990’s. Creo has some pre-press software developed about a decade later that is vastly superior. However, there were some unique features that were needed to be developed and added to Creo’s software suite.

Project management for the customer was being coordinated out of head office in mid-US whereas the printing technology was based at plant site near the West Coast. I flew down to the plant to show off Creo’s software suite and capture requirements. Did the presentation, flew back to Vancouver. A couple of weeks later, we get the diplomatic message from head office that perhaps all the requirements have not been captured. So I fly down again. I also arrange to have Creo’s software suite loaded on a server and shipped to the plant site as a loaner. This time, during the presentation, they have their super-user, their system administrator on hand. I am lucky that the customer is smart enough to get their users out to the presentation to critique the suite. The super-user goes deep on me. That means she drills down many levels to some really obscure (to me) but important (for them) business requirement that is not in our software suite. I promised to follow up on those features with some of Creo’s SMEs (subject matter experts) when I get back to the office.

Meanwhile, the server with Creo’s software arrives on-site with a local field rep to do install and preliminary training. I also arrange for a trainer to follow up with an on-site visit to the customer a week later. I pre-brief the trainer to watch & report for any new requirements. Six weeks later, I send another trainer. About five months have passed since my first visit to the customer suite. Finally, the super-user is able to articulate the requirements that the plant needs to the Creo representative who is also a SME in that particular sub-topic. So we get the requirements captured and we pass them on to the development team and we get the message back that none of the requirements are impossible to fulfill, it will take about three months to roll into the next upgrade. End of story.

Now, note that in this case study:
1. The customer was sophisticated, understanding that we needed to have the super-user spend lots of time playing with our software so she could discover what was missing.
2. We had lots of time. Getting the proper requirements took five months. Coding the requirements took two weeks (the administrative load of rolling new upgrades into the software suite accounted for the other 2.5 months).
3. This was a modification of a pre-existing software suite. We were not presenting the customer with a “blank piece of paper.”
4. The business was worth enough to send a loaner server with the software to the plant AND have a total of five separate visits to the plant (two trips by the project manager, one by a local representative, and two by trainers).

In conclusion, the point of this essay is that getting requirements in the real world is not so much a point of documentation, but an iterative process with the customer that goes on through the life-cycle of the development process (and beyond).
I’m gonna try to finish the book I’m reading, if only to present myself to future employers as fount of (conventional) wisdom. But really, if the woods are full of project managers who think they are home-free once they document the requirements of a project at the beginning of the development cycle, then it’s no wonder that a lot of them get shredded after a few years in the biz.

This post is a synthesis and continuation of some ideas that have been covered in other posts on this blog: Why volatile investments sucks, the 85/95 rule of project management, and Gantt charts versus PR database. If you have read all of those posts, then what follows might make sense to you. If not, then I guess we’ll see just how good a writer I am.

To dumb it down somewhat, I’ll use one of my favourite literary devices: The parable. Here is the story of Ploddin’ Paul the project manager who is faced with a very difficult management decision. He has a team of 5 developers, of which three are senior developers and are capable of handling mini-projects on their own. Their names are Genius Gary, Engineer Eric, and Liason Larry.

The project is a somewhat risky one, but not overly so. The goal is to build an archiving interface to several different models of tape drive so that customers logging into a database have the option of leaving their data on-line, saving it to a tape drive, or restoring the data from tape. Of course, there are number of other features and design requirements. The project is to be delivered in 6 months.

The team has three choices: 1) Write the code from scratch 2) Re-work some existing code that was produced in-house or 3) Work with a third-party API that promises to deliver much of the functionality (published by a vendor called Babooza).

“The APIs of Babooza suck big-time, let’s do it the right. Write the code from the ground up in C#,” says Genius Gary, who is the best programmer of the lot but has the attitude to go with it.

“The least risky way is to re-work our existing code base,” Engineer Eric says. “We already know how difficult it is to work with the drivers for the tape devices. Yeah, there’s hair in the old code base but that’s the devil we know.”

“In six weeks, Babooza says they will deliver an API that takes care of most of this.” says Liason Larry. “Why do any of this if those guys will do it for us?”

“Trust Babooza? You’re nuts. And our old code base sucks. Everybody knows that. Go new.”
“I agreed with you about Babooza. But you want to leap off into deep water with no lifejacket. Go old.”
“But what if Babooza delivers something functional? We’ll could have our developers add more features and a really good GUI instead of goofing around trying get the tape drives to archive.”

At this point in the conversation, just about when the developers are about to run to their desktop and settle the matter by playing a deathmatch in “Unreal Tournament,” Ploddin’ Paul speaks up:

“Larry, what do you think the odds are of Babooza delivering the API on time and it being usuable?”

“Ah, I dunno, maybe 50%”

Both Eric and Gary make noises and Paul marks that down to 25% in his head.

“Gary, if and another developer work on building what we need from scratch, do you think we can ship on time?” asks Paul.

“Naw, too much work, I would need at least another guy.”

“What if I gave you a guy three months in? Maybe two.”

“Okay, 80% chance of being done on-time.”

Now it’s Eric and Larry’s turn to roll their eyes. So Paul marks down the odds to 40% in his head.

“Eric?”

“C’mon Paul, give me the whole team and ninety percent sure it’s going to be delivered.”

“Hairier than the back of a gorilla,” Gary says in a loud whisper to Larry. “Think spa-ghetti.”

“Eric, if you’re just re-working the code, how come you need headcount of five?”

“Come on, the more the merrier. There is going to be a lot of debugging.”

“You get one guy for now, with maybe more in three months. So are you still 90% percent sure?”

“Ah, no promises,” says Eric

Paul mentally marks the odds down to 50-50. He has had a look at the code. It’s terrible.

Paul makes his decision. “Everybody go off and do their own thing. We’ll come back in three months and review.” Everybody nods their head and walks off. It was always like that, with Paul never making a decision on the final path to take until the very last possible moment. It drove some of the developers completely nuts sometimes, with the odd grumble that the group always seem to be on the verge of complete anarchy. But Paul DID let everybody try their own way most of the time, so people were most happy. It just seemed so inefficient…

***************************************************************************

So, on first read, it looks like Paul is violating one of the golden rules of project management which is always work hard to change your 85s to 95s (that is to say, always try to up your odd of success, no matter how incremental it may be). Paul is forsaking some paths which promise a 90% percent chance of success and letting developers pursue some high-risk approaches. Also, I have to say that this approach would look like crap if you threw it up on a Gantt chart: Instead of clean little bar showing five developers working together as a team towards a common objective, you’ve got three bars working in parallel towards the same goal. At some point in the chart, you’ve got to end two of those tasks, with all the waste of resources that implies (In Paul’s case, the decision point is halfway into the project or three months).

To summarize: The developers do not think Paul is a decisive project manager, and definitely, if Paul’s boss lived and died by the Gantt chart, he would wonder why Paul was wasting resources with all the redundacy.

But once again, the math works for Paul, because in software development, parallel paths with a reasonable chance of success are a better than one path with a high chance of success. Note that parallels path means you add the percentages together, not multiply like in a sequence:

One path: 90% of success.
Three paths: 25% + 40% + 50%= 115% of success!!

Of course the 115% doesn’t mean that the project is absolutely sure to be completed successfully and on time. These percentages are gambler’s percentages, meaning that sum is the addition of a series of bets for a given payoff. A metaphorical story might make things clearer.

Let’s pretend we are in casino rather than in a software development environment. You have $500 in your pocket and the prize is…Oh, I dunno… an brand new Ipod (The best version, the one with 40 gigs. The one my wife won’t let me buy ’cause I don’t have a job, even though it would make me really, really happy if I could).

You can place all your money on one bet and have a ninety percent chance of winning. Or you can make a more complicated series of bets like Paul did: You put down $100 and have a 25% chance of winning. You also simultaneously put $200 down and have 50% chance of winning and put down another $200 to have a 40% chance of winning.

And here is where the fun comes in: With the first bet, there is one spin of the wheel and you know whether you are a winner or a loser. If the estimate of the development is correct, you are a winner nine times out of ten.

But with the three bet scenario, you have three spins of the wheel, and if one of the spins comes up a winner, you get half your money back from the other two bets. For example, if one of the $200 bets comes up a winner, you would get back $150 (50% of the $100 and $200). That is to say, if Gary’s approach looks to be a winner after three months into the project, then you can abandon Larry and Eric’s approach.

But what happens if none of the bets comes up a winner? Aha, well if that happens, the casino will allow you to double up your bet and spin again, taking half of the total sum of your bets ($250) and allowing you to spin again (With the chances of success not know until after the first 3 spins are completed). That is to say, if after three months, the API from Babooza totally sucks, and Gary’s team can’t even do a daily build without the compiler going into hysterics, then Paul can make the decision to throw everybody on Eric’s project to rework the old code base.

In short the complex, almost chaotic allocation of resources in a software development environment allows for a better chance of a project being completed, and for a more efficient use of developer resources. I stumbled across this discovery mostly by accident, when I was grumbling about the inadequacy of gantt charts to accurately describe what really goes in a true development environment. For sure, I didn’t expect to find a mathematical proof for the behavior that I saw in the PWS (software) division of Creo.

Anyways, for me this is a really cool discovery, because it validates the everybody-run-around-and-do-your-own-thing-and-let’s-make-a-decision-later approach. Well, I mean the math validates the theory. Hmmm, I don’t know if I would to try to “sell” this approach in a job interview or something like that.

Cheers, Dj

P.S. If, in software development literature, anybody has come across ideas similiar to the ones presented above, please drop me an e-mail so I can link to it. It’s quite possible (maybe even probable) that this “Anarchy is Good” theory has already been discovered and I am just ignorant of it. Thx.

The content for this website is provided by www.bluebutterfly

You turn on the water in the shower, it’s too cold. You adjust the tap, still too cold. Adjust the tap again, still too cold. One last adjustment, and you’re in the shower. Ten seconds later, you’re jumping out of the bathtub with scalding water raising red marks on your bare bum. Welcome to latency. By the way, what’s your I.Q.?

Software development is notorious for having very long periods of latency. At Creo, it was quite common for a software release to take more than a year to develop. Heck, a major piece of software can take up to half a decade from conception to stable release. Six months of development gets you a service pack for most applications, and nothing more.

Think about this for a moment: Let’s say you are a senior executive or an angel investor or a investment banker and some software development guru comes up to you and wants $2-5 million dollars and two years to develop a groovy new piece of software. What you do say? Well, if you are in the making-money-from-software-development-business, you either say yes or you say I’ll-think-about-it. No is what you say to guys who say they can build something in a year, because they are full of baloney.

Off the top of my head, I can think of three major engineering projects (two software, one hardware) where the senior management team spent years and millions of dollars on the develop team and where the execs were told lots of time by the people around them that they should cut their losses. But no, they kept flushing money down the toilet to the point where everybody thought that the execs were nutty and maybe a bit incompetent. And you know what? At one time in the past, those execs were thought to be really smart people. So what happened?

Latency. It’s that simple.

You can’t kill a project because of bad-word-of-mouth. Anybody who has spent some time in the R & D business knows that the first version of any product has serious shortcomings. The first Macintosh had bad vibes. In developing the first postscript driver on the Apple computers (and thereby kickstarting the electronic pre-press revolution), the lead developer had a nervous breakdown. Everybody thought that the Windows NT development was going down a rathole and would never come out again. Look what happened. (Of course, they then took a lot of that same team and put them on Window for Itanium ie 64 bit-computing and they DID go down the rathole never to return)

Personally, when I joined the Prinergy team (then called Araxi) back in 1998, I was given a whole bunch of well-meaning advice by a few people not to go. Apparently, there was some doubt at the time as to whether the whole thing would get off the ground. For example, some of the middleware vendors were peddling crap. The senior engineers and the SMEs were fighting over specs (oh boy, never heard that one before), developers were leaving the team and some critical bits of the system, like the Java client, just ran too darn slow and nobody could figure out how to make it run faster.

And today? The project manager of Araxi aka Prinergy One is senior VP of the PWS division of Creo and last time I checked, virtually every major commercial printer in the world runs Prinergy in their shop.

Whatever. Sometimes latency works for you. I mean, sometimes, if you just sit back things work out okay. On the other hand, sometimes if you just sit back, the horrendous hand of fate will ball itself into a fist and keep whacking you just below the waistline. And it’s just unbelievable the number of very smart, very sharp people who end up just sitting there with their hand over their family jewels, taking the shots.

So if you work at a small company, you generally don’t have the problem of stupid procedures sucking up your valuable time and draining the morale of your team members. Instead, your big problem is resources, or lack thereof. Like maybe you have one person doing coding, documentation, quality control and marketing. And that person is you.

At big companies, if you’re lucky, the problem of resources constraints is not as insurmountable. Instead, dealing with bureaucracy is oftentimes your number one problem. What this means is that for you to access the coding/documentation/quality control/marketing resource, you need to follow procedures. Or crack the secret code. To clarify: Lots of time nobody tells you the proper procedure but they just expect you to follow it. I can’t remember the number of times I would locate somebody in the Creo organization who had a resource I needed, and when I made contact, I would first receive a lecture on the importance of following procedures and why the hell didn’t I do that first instead of bothering them? Then, they would show me the secret web site on the company intranet that had the form I needed to fill out in order for the system to process my request.

And this is not to dump on Creo. From what I understand every organization over four hundred people, whether public or private, tends to do this. You can protest all you want, but you might as complain about excessive moisture on your socks after taking a pee against the wind.

Of course, by no means do you have to follow procedures. Sometimes you can get what you want by screaming loud enough. This approach tends to be especially attractive if you are a young and frisky project manager and you’ve had a couple of frustrating work-days. You can even get away with this approach if your project is An Important Matter and also if you report to somebody really senior. For a few years at Creo I reported to an executive VP (at least that’s how it showed on the hierarchy chart) which is better than reporting to a regular VP or even a lousy director. It was great for two reasons: One, I could safely antagonize anybody and everybody up to the level of director without my boss feeling threatened. Two, executive VPs at Creo were really, really busy people so they wouldn’t even take the time to discipline you unless you were running around the building wearing a clown suit with the pants missing. Well, actually one time Stan chewed me out but that was because I totally upset the prez, which actually proves my theory.

However, even with the awesome discretionary power of being able to whiz on the shoes of anybody in the org excluding the senior management team, I soon learned to restrain myself and work within the system. There were many reasons for me making the transition from crap-disturber to team player. One reason was early in my career I worked under a guy who was a great leader but a not-so-good manager. Any tiny bit of red tape would drive him crazy to the point were everybody in the bureaucracy rebelled against his screaming and went totally passive-agressive. And he couldn’t get a damn thing accomplished. I realized that if I continued down the path I was going, I would end up like him. And what is a project manager that can’t push anything through the system? Absolutely useless.

So I started to fake interest and listen to people and ask questions as to why this procedure was put in place. And more times than not (but not always), there was an understandable (but not always good) reason as to why that procedure was put in place. A good rule to remember is: No procedure is stupid at the moment of inception. That is to say, it always seems like a good idea at the time to put the extra step in.

Why is it sometimes important to know the origin of a procedure? Because it helps you to come up with an alternative that is satisfactory to all parties if following the procedure as it stands is just too painful. Another good reason to follow procedures is a lot of time they allow people to form abstractions about what you are doing. And in a big organization it’s important to have abstractions that mean the same thing to a wide body of people. This may come as a surprise to you, O great leader, but not everybody in org has the time to read your weekly updates or the energy to expend the effort to understand why your project is so unique and special. If you are following the procedure and not antagonizing (too) many people, then all is well with the world (meaning they won’t block you and even perhaps release some resources to help you out). Don’t underestimate how important it is to have solid abstractions in a large multi-national corporation. Let’s see you have some procedures for rolling out a new product. You don’t like the procedures? Fine, get on the phone to Brussels, Hong Kong, Tel Aviv, and Boston and tell everybody you’re changing what beta means and early production doesn’t include documentation because you think it’s stupid to get stuff written at such an early stage. Let’s see you get everybody to sign off on how you think stuff should be done.

On the other hand, slavish obedience to every darn procedure that is drafted in head office is by no means a guarantee you’ll get the project done. This is where experience comes into play. It can take years, years I tell you, to develop such powers of discernment that enable you to determine which procedures are crucial to follow and which can be safely ignored. Here is a rough guide:

1. All procedures laid out by salespeople should be followed. Salesguys hate procedures, absolutely loathe them. So if the sales office actually comes up with a procedure, you probably should be following it.

2. Procedures by your foreign branches should be followed. Even if the procedures seem really weird. Especially the weird ones.

3. Procedures by the budget team. This is a tricky one. If money for projects is flowing like a river and your company is doubling in size every years, you can oftentimes ignore them. But if money is tight and the rumour of cutbacks is making the rounds, then follow their procedures to the letter. Unless you really did want your budget cut.

4. Any procedure by a business analyst or a consultant can be safely ignored unless it’s given a seal of approval by your boss or by somebody who your boss respects.

5. Customer services procedures can be safely ignored EXCEPT for those procedures recommended by those people who actually deal with directly with customers. I’m not kidding, in every large company there are people in the customer service division who have never ever SEEN a customer. And these people are the worst at making up stuff that is just a pain to follow.

 6. IT procedures. Find the guy who wrote the procedure and confront him. If he can defend it, then honour it. If he got the procedure out of a Dummies textbook, tell him to compromise or you’ll start an insurrection.

7. Procedures by the datacenter people (SAP, Oracle, Peoplesoft): Follow them only if the data people give you resources so you CAN follow them. That is to say, the SAP guys should be given you face time with the database administrators to work the system to get what you need. Ditto with Oracle and Peoplesoft. If all they are doing is sending you e-mail with hyperlinks to undecipherable database GUIs, then you can safely ignore them. Because they are probably doing the same thing to your boss and bosses’ boss, and as a result, everybody in the org hates them.

8. All procedures that release resources that enable a crucial task to be completed should be followed, no matter how stupid. Fight the good fight in the next life, not this one dummy. 9. If it will annoy your boss to not follow the procedure, then follow the procedure. James Dean could be a “Rebel Without a Cause” because he had tons of natural charisma and was incredibly good-looking. However, if you follow Dean’s example, you will just come off as being irritating. In short, you gotta push the paper and kiss the rings of the various bureaucrats to get stuff out the door. Unless you’re the CEO. And even them, I’ve seen at least one CEO slap his forehead when dealing with SAP.

Oh my heavens, you’re a bright shiny new manager, you’ve been given a glorious new project to lead and what’s this? You can’t even go to the can without the janitor giving you advice on what you are doing wrong and how to fix it. How ever did the world turn into such a cruel, callous place? Just wait, it gets better. There was never a product launched nor a project completed if only the person-in-change hadn’t been such a bullhead and not listen to the advice of those around him or her who knew better.. why this reminds of me of that blockhead…Blah, blah, blah.

As you may have guessed by now, an essential skill-set that is acquired by the rookie project manager in any middlin’ to large organization is ability to respond to and/or ignore criticism. Most PMs learn to block it out. Some don’t, and return to being engineers or technicians. Some become PM in name only, choosing projects that are in maintenance mode and avoid dealing with criticism that way. Which is a shame, because if there is one thing that is sweeter in seeing a project completed to success, it’s seeing a project succeed against a chorus of naysayers.

Of course, some PMs learn to block out not only criticism but good constructive advice, acquiring a siege mentality and tunnel vision which leads the whole team to disaster which could have been easily avoided. So blocking out everything that is said about your project is not a great approach either. It can be a real quandary: On a hot project, you can have so much criticism/advice coming your way that you can spend all your time dealing with the advice-givers and validating/disproving their comments. And lots of time the advice-givers are those higher up in the food-chain whereby ignoring them is perhaps not the best way to enhance your career prospects in that particular organization. So what to do?

It is important to realize that not all criticism is the same, and to differentiate your response to each one of the flavors. In my opinion, there are four types of criticism: Noise, constructive, delaying, and blocking. I will deal with each in turn.

Noise is an e-mail or a hallway conversation, or even an off-hand remark in a staff meeting about your project that is critical. Noise is criticism given without much thought or consideration, and is also hard to validate without considerable expenditure of resources. The last part is important. Every once in awhile, you can have a hallway conversation with somebody who throws off an off-hand remark that is really pertinent and is actually a really useful bit of advice. Or they suggest a different way of doing something that is more economical or quicker than the way you are doing it at present. But of course, a lot of time noise is just that, noise. You can really determine the value of the criticism by actually visualizing a plan of action if you were to actually take the advice: Re-write the entire code base in C # instead of Visual Basic even you though you have a drop-dead date for shipping next week? NOISE.
However, you should never duck noise because it might not be noise, it might be a beautiful piece of music that you need to hear at just the right time. Another equally good reason why you should never duck noise is because you want people to bitch to your face, not behind your back or worse yet, to members of your team whose morale you are responsible for. I mean, that’s one of the basic responsibilities of a PM, taking arrows in the bum that were meant for your team.

Constructive criticism is entirely different: It’s feedback given in a controlled environment according a reasonably clear set of guidelines. A code review or product milestone meeting should give up a reasonable amount of constructive criticism. BTW, none is not a reasonable amount, unless you are some sort of genius (which is doubful). More likely, if you present at one of these meetings and you receive zero feedback, it most likely means that nobody cares about your project (this is bad). So let’s assume the best and that you do receive criticism/advice/feedback at these meetings, what to do? The best response is to just acknowledge the criticism and move on. If the critic (who often times is the chair) demands an answer, then you should respond as best you can at the present time, and negotiate a reasonable time period as to when you can provide a full and complete answer. But always make sure you know the guidelines of the meeting. They are usually there to make sure that no impasse will occur, which usually embarrasses everyone. But note at some of these meetings, you are expect to show a certain amount of grace under pressure, so you need to do your homework and prep for the ritual ball-busting if that is the usual ceremony. It actually doesn’t hurt sometimes to admit that you were wrong in whatever the topic of the conversation is, especially if the critic is somebody who has vastly more experience than you in such matters.. And gees, if you are wrong, you should admit it. There is nothing more pathetic at these meetings than somebody who loses control of their ego and desperately clings to one side of an argument that has been abandoned by everybody else at the meeting.

Delaying and blocking criticism can appear to be quite similar on the surface but actually spring from two very different base motives. Delaying criticism occurs when the critic isn’t quite prepared to support you in whatever marvellous endeavor you are undertaking. Of course you should only care if the critic has resources that you need (which is about 99% of the time). For me personally, it’s absolutely amazing how often delaying criticism can be handled successfully by just giving the critic a reasonable amount of time to think things over. For example, suppose you need a developer to write a patch in their code branch to make your component work successfully. If it’s more than a trivial amount of work, there is most likely going to be more criticism about your need than agreement that the patch needs to be created, at the first meeting. However, give it 24 hours or a couple of days, most likely you’ll get your patch, especially if you stay pleasant and calm through the whole negotiating period.

Blocking criticism is a whole different ballgame in that you can wait until the Maple Leafs win the Stanley Cup, and you still may not get that stupid patch. However, the script of the blocking critic is oftentime similar to the delaying critic, so you need to really analyze the interaction between the critic and yourself and determine which type it is (Note: There is presumption here that you need resources from the critic. If you don’t need anything from this person, you are free to file the criticism in the mental file folder labeled: Noise). If you are stomping around on their tuff, you are most likely to encounter blocking criticism. If they get theological on you (like Unix versus Windows, or C # versus Java), then it’s a block. You are then faced with a series of choices: 1) Proceed without the resources of the critic. 2) Get somebody in authority to beat on their stubborn heads. 3)Ask them what has to change for them to drop their criticism, and decide if you can live with their changes. Option # 3 is usually the best if you can swing it. Option #1 is the fallback if #3 is impossible, and a lot of times the critic will capitulate if they see you have a chance of success without their contributions. I don’t ever recommend #2 unless you are in some sort of weird authoritarian organization like the KGB or if your executive sponsor has a very clear mandate to push stuff through a dysfunctional organization. Even then, I wouldn’t be banking on collecting a pension at the place if #2 becomes a standard part of your PM toolkit.

Final bits of advice: Get a sense of humor. Don’t take it personally. And remember that organizations have incredibly short attention spans. You may be in hurricane of criticism one week and think that it will never end, and the gossip next Monday at the office is not you but the manager in the next building who was caught fooling around with the marketing communication officer in the storeroom.

And what will you feel? A bit of resentment that you are not the center of attention anymore. Such is the emotional silliness of a human being.

…And why it sucks.

So I was having lunch with this guy from Mainframe (www.mainframe.ca) and we were talking about a lot of stuff: What Creo was like in the good old days, what’s up with the local high-tech scene, and of course, the topic of project management, especially in the field of software development. I of course had a bit to say about managing software development projects but I held back for the most part so as to not suck all the oxygen out of the room.

Therefore, it’s wonderful to have a blog so one can vent out all the wonderful musings in your head, for I can safely assume dear reader, that you want to be here. Or that you are so stupefied with boredom that you cannot even expend the energy to click your mouse and hyperlinks over to some other web page. Same difference for me.

Anyways, the secret is very simple: Change your 85’s to 95’s and you are a good project manager. Of course, nobody realizes how important that is and you won’t get much credit for it. But trust me, that’s what a good project manager does.

Say what? You want elaboration? Oh, okay. I love to talk anyways….

Most people underestimate the fragility of non-redundant complex projects. That is to say, uncertain events that must be accomplished in a sequence are prone to failure to a greater extent than most people intuitively realize. For example, suppose you have a project with three separate main tasks and each task is 85% certain to be achieved in the time allotted. What are the chances of the project being successfully completed on time? Eighty-five percent? Eighty percent? How about seventy percent? WRONG baby, the chances of that project completing on time is 61 % or (85% x 85% x 85%). And a project with three main tasks is a simple, simple trifle that’s not even worthy of a full-time project manager.

Even though the math says that less than 2 out of every 3 projects will be successful with those kind of odds, most people intuitively think the chance of success will be higher. But don’t take my word for it, pose some hypothetical questions around your office: Say you have this project with three things that are 80% plus sure of happening. How often should the project manager deliver the goods, and how often should he be allowed to fail? EVERYBODY will say a 75% or higher success rate for the project is a reasonable expectation.

(Allow me an aside here: If you try this at your local employer & you get the right answers from more than one person, please e-mail me IMMEDIATELY so I can send my resume to where you work)

The remorseless logic of this simple mathematical equation absolutely means that those who survive in project management are those who focus on the 85’s and change them to 95s. That is to say, up the success rate of a project from 61% to 86% (95% x 95% x 95%). This means that for every five projects, four of those will be completed and/or be finished on time.

Now that you know the really big secret of being a good project manager, you are probably thinking hey, this is great, now I can make the leap to becoming a manager instead of being a coder/engineer/starbucks barista. And if you are thinking that, that means you have not yet considered the implications of focusing on just that 10%: Why it sucks. Here are five reasons:

1. The 85/95 rule means that you don’t have to watch out so much for the stupid & lazy people, but the clever gamblers. The really clever people on your team love to do bleeding-edge type development because it’s cool and interesting. They don’t really think (or care) that moving the success percentage from 95% to 85% of their assigned task is such a big deal. This means that you, as project manager, have to yank them away from the bleeding edge or try to compensate for their gambling elsewhere in the project.

2. If you are doing your job properly, you are only focusing on the critical 10% of 3 or 4 task where you can make a difference. It means that you are not doing any real fun thinking stuff, but mostly carrying water for other people…. Who don’t understand why you are kicking up such a fuss over a lousy ten percent.

3. Unless the person above you is a very smart/experienced executive, they are going to get upset with you for expending a LOT of resources & time on the critical 10% of three or four subtasks.

4. At review time, members of your team will think that you contributed “on the margins”. That to say, you made an impact on 10% of whatever that subgroup accomplished. So maybe they will give 10% of the credit. So at review you will have 3 or 4 subgroups saying you deserved marginal credit.

5. The really fun projects with big paybacks usually have one task that’s at 70% (or lower). Watch what happens when you plug that percentage into the sequence: 70% x 85% x 85% = 51%. So it’s a fifty-fifty chance of success. Get used to failure if you want to keep signing up for the fun stuff. More importantly, get your BOSS used to you failing if you want to keep having a job.

In conclusion, there is usually a shortage off project managers in product development groups, especially software. And the math above combined with people’s intutive’s expectations of success is pretty guaranteed to make sure that shortage extends into the future.

But darn, it sure is cool when a project comes together against the odds and takes on a life of it’s own. Even if very few people think you did anything to help make it a success.

So you do consider yourself a good poker player? Okay, so what is the significance of this number: 50.1%? How about this number: 42%? Very good, how about this number: 2.1%?

Answers: Chances of getting no pair in a pat hand of 5-card poker. Chances of getting a pair. Finally, the chances of getting 3-of-a-kind.

If you didn’t know that, and you considered yourself a semi-decent poker player, then you are such a suck—…. …such a wonderful pleasant individual that I would like to know you better. Please drop me a line, we’ll get together sometime, relax, and play some poker. Bring lots of money.

Most people do not play poker think it’s a pretty simple game with a large dollop of luck involved and the skill is in the bluffing and reading of your opponent’s poker face. Actually, in the long run, there is very little (none) luck involved and most professional poker players bluff about as often as I pass up on a cinnamon bun from Cobb’s bakery. Which is to say, very rarely.

What most professional poker players are good is risk quantification, or processing a number of mathematical probabilities in their heads to determine if they should check, raise, or fold. Very infrequently do professionals, over the long run, deviate from what the odds tell them to do. Unless you enjoy grinding a lot of variables in your head, or paying money top enjoy the social aspects of getting together with the boys to play a few hands, you should stay away from the game.

Um, if you disagree with my previous conclusions so far, maybe we should talk about further. I don’t want you to turn away from this blog without reaching some sort of consensus. Perhaps we should get together to discuss these ideas further, over a pint of beer and a game of cards. I’ll bring the cards. You bring your pleasant personality, your engaging intellect, and lots of money.

Anyways, back to the essay. Some people like to calculate odds in their head. Some people are very good at calculating odds in real-world situations. These types of people tend to become project managers, among other professions. Project managers know intuitively that if the percentages are in your favor, over the long run, you will be successful, so they tend to be more comfortable with risk & uncertainty than the average manager. Intuitively, they understand that OODA loops are one of their most powerful tools to mitigate risk. They instinctively shy away rookies and gravitate towards the veteran, not because of questions about competency but because of risk assessment capabilities.

Most important, like a poker player, most good project managers won’t give up a 1% shift in the odds without fighting, and walk away from the table with -5% shift against them, unless the stakes have been re-negotiated.

I don’t know why, but most people don’t grasp the importance of a 1-5% shift in odds in a culminative scenario. That is to say, if you do something once, then a 5% shift in the failure/success percentage can perhaps be ignored. But if you are doing something 20 times over, then a 5% swing is HUGE, and even a 1% swing is significant.

Most times, when you point that out to people, they say “Yeah, yeah, yeah, I get it” and then their eyes glaze over as they contemplate their next vacation to Las Vegas or put more money in mutual funds with the 2% administration fee. Or they pass up the chance to renegotiate their personal finance loan from 12% down to 7. I don’t think it’s an intelligence issue. It’s just some (most?) people don’t care about culminative impact of the odds. And they never will.