Category: Articles

Home Articles ()

Burning it down

One of the most interesting project management reports that evolved after my start in the industry is the “burn-down” report.  I Burndownreportmention it because at HMS, we are about to launch TimeControl 7 and we are in the final hours prior to launch where we are at the end of a long reiterative burn down process.

If you’ve never been in the IT industry then you may not have seen such a project management report with this title but the concept is not unique to the IT industry.  In construction project management we tend to think of this as the “Commissioning List” or the “Commissioning Report”.  It’s a list used in the final stages of the project of everything that is incomplete.  In construction, you have a list of things you know need doing, but as you walk the project in the final weeks, days or hours, you and your staff keep a list of things that you notice.  Paint that didn’t go quite to the end of a corridor, a pipe that is exposed but was supposed to be hidden, refuse from a contractor that was never collected…  And so on.

In my world in IT, we have a list of outstanding items that have been discovered in the QA process.  Code for our next version was completed some time ago and numerous people are working through the product over and over and over trying to make it break. Each time they do, or they find a discrepancy of any kind, they list that in the outstanding list of things to resolve and that list becomes the count of items in the burn down report.

As you can see by the example here, the reason it got the name it has is because you keep hammering at the report day after day, trying to burn the list down to zero.

One of the aspects of this project management report that I find fascinating is that a single view of it is not reflective of the entire process.  It is the progression of the report that is useful.

When we start a burn down report early in the QA process, it is not uncommon to see the numbers of issues rise.  In fact, if we start the report too early, it may rise very quickly.  For the uninitiated, this can be disturbing.  “Why is Testing finding so many problems?” management may ask.  They shouldn’t be upset.  Every issue you find in the lab is solved with a tiny fraction of the time and heartache it will take to solve the issue once the product is released.

In a normal process, the report tends to looks like rolling waves that get smaller and smaller over time.  Some reports, as are ours, show different categories of issues, some lump all the issues together.  We prefer to show the critical issues distinctly from the less critical issues.  We have to resolve them all of course, but reading and analyzing the report gives the senior staff a good idea of where the product is going.

Let’s say that as you are getting near what you believe is the end of the QA process, new critical issues continue to be added.  You should take caution that you aren’t as far along in testing as you should be.

On the other hand, let’s say there has been no report of any critical issues for some time and the moderate issues have died off also.  What is left are the low-priority issues and even those are now approaching zero.  We update all of those, do a new cycle and see if we’ve resolved those, make sure we haven’t broken anything else and check to see if we’ve burned down the issues all the way to the floor.  We’re pretty much there with TimeControl 7 and as a result we’ll be packaging it and getting it to market in the next couple of days.

If you’re working through your own burn-down list, know that you have my sympathy and that there really is light at the end of the tunnel.  Think of the satisfaction of printing that particular report and seeing a message that says “No data to report!”

Striving for nothing in this case is a worthy goal!

Why would you want to write that software yourself?

I tend to look at someone’s decisions or the actions they’ve taken and wonder “What was the world they were looking at that would have had those actions and those decision seem like the exact right thing to do?”decisionmaking_300x200.jpg

Now I know that not everyone thinks like me and thank goodness that’s true but for me in a business or project management context, asking that question of myself can become quite important.  You’ll see the results of my pondering in numerous writings here on the blog as it has come up in many different contexts.

Think about portfolio project management (or project portfolio management if that’s your preference) for a moment.  There are many different portfolio analysis tools on the market and all of them deliver empirical results on which project should take a higher priority in order to deliver better value to the organization.  If you follow the processes that come with such products, you end up with valuable introspection on how your business valuates projects and what drives the business.  That alone would be a worthwhile exercise but when these values are applied to projects the list of what projects should be activated and which not becomes reasonably clear.

Portfolio software salespeople produce beautiful charts showing graphically how this will improve the bottom line to the organization just by selecting the right projects.

And yet, there is resistance to implementing such a system.

Why?  What world did the executives who protested perceive that would have them say “Portfolio Analysis?  That’s a terrible idea!”  Well, ok they never say that.  Instead there is a litany of odd and non-sequitur responses that result in the initiative dying on the table.

Yet, when you think about the people in those roles you might find, for example, that their compensation is tied to their projects being a success (as I once discovered) and that having their project not be priority 1 would result in an actual loss of personal income.  I’d expect that anyone facing such a decision could be expected to vote in favor of what’s good for their own family.

Another counter-intuitive situation seems to be more and more common in the last couple of years.

For quite some time it was apparent to most people that the idea of writing their own corporate timesheet or project management system was a terrible idea.  The cost of creating new software is always more than the sheer development cost.  I created a white paper comparing this some time ago.  Buy it or Write it? can still be downloaded and read on the TimeControl.com website.  It shows that creating new software includes doing your own design, writing the code, then documenting it, making help for it, providing ongoing technical support and ongoingly updating it which isn’t optional as all the operating systems and underlying architecture the system was written for is changing all the time.  The overall costs made it prohibitive to write your own product.

When you think about this idea separate from the calculations, it passes a reality check.  If you write an enterprise tool for your own use, you are amortizing that development and total cost of ownership over one client; you.  If you’re a commercial software developer like my firm HMS is, then you are amortizing the total cost of development and support over hundreds of thousands of users and hundreds or thousands of clients as is the case with our TimeControl timesheet product.

So why then, more recently, would this idea of writing an enterprise product here in the office, return as a supposedly great idea?  What world are the people who are speaking to me about this seeing that makes this a sensible choice?

One possible answer came to me just a few days ago.  Today’s development world looks nothing like it did years ago.  There is a massive outsourcing community where the costs of development are much lower than developing locally.  It’s true that you must devote more money and time to more senior local personnel to design, document, project manage and communicate the ideas that the business needs, but the actual developers are less expensive and it may still be attractive.

Even more significantly, if I’m the leader of an internal offshore development team then my day is probably largely spent investigating opportunities for my offshore developers to work on.  I’d be in sales mode all the time, even if I’m part of an internal team.

Suddenly the argument I’d make to a business who is looking for enterprise project management or timesheet software that a commercial off the shelf package will be more economical and do so much more for you than writing something yourself may fall on deaf ears.

I might find that I’m unknowingly speaking to the very person who is managing a large team of offshore developers all of whom are eager to create such an application themselves.

So, I’ve had to dust off my Buy it or Write it white paper to do some editing.  It was overdue anyway.  These days, the options are more likely to be Subscribe to it, Buy it or Write it yourself.

The basic premise is the same though.

Is it your core business practice to be the publisher of an enterprise project management tool?

If not, you’re spending time and money creating something that will only ever have one client.

Are you sure that’s the right decision?  Consider all your options before deciding.

Avoiding Project Political Correctness

This year political correctness seems to be everywhere.  In the US it’s a presidential election cycle so perhaps some level of political correctness goes with the territory.  But political correctness isn’t just a political phenomenon.  politically_incorrectd_300x214.jpgIn the private sector, in public sector organizations, in volunteer or charitable work the insidiousness of being “PC” can wreak havoc.  Project Managers are faced with this every day and are under pressure either to make sure their project reports are politically correct or that they comply with the politically correct responses required when asked.

Here are some ways that being PC can affect how a project management office functions:

Use only praise, never criticism

Anyone who has ever been a parent or a teacher knows how poorly this works.  So, when someone does something that doesn’t work, you’re expected to ignore that; to “give it space” and to focus on the praise of the person who made the error.  In my experience, praise is worthless if it’s the only thing that you ever express.  Saying, “We want to congratulate the ACME project team for their 5th week with no spelling errors in their report,” when the same team missed a major client delivery milestone isn’t productive.  What happens when you adopt this practice is that errors are ultimately treated like they’re acceptable and praise becomes meaningless drivel.   I’ve adopted the practice of noting when someone does something that made a positive difference and noting when someone does something that makes a negative difference.  Now, to be fair, if you only focus on criticism, not praise, you are likely to also end up with terrible results.

One thing I’ll say about this though is that there is a huge difference between pointing out behavior and results than referring to what someone is.  You will never hear me say “You’re stupid to have done that.”  I’ll say “That was a bad plan and it has produced bad results.”  Seem like semantics?  Not so much.  If you keep saying someone is incapable, they’ll ultimately prove you right.  Ineffective actions can be corrected.  Being someone ineffective might not.

Speak only of the positives, never the negatives

The positive thinking movement got this practice going years ago.  This is like a bank account where you’re only allowed to record and manage the deposits, never the withdrawals.  A couple of decades ago, I went through a period of time where my firm, HMS was struggling.  Every company that’s been around for 30 years has periods like this.  They’re never fun but a small, maneuverable firm like our own has been able to weather them quite well.  Not that particular one though.  It turned out that our accountant had not wanted to share any “bad news” with management.  So, she devised a plan.  She would track our revenue on an “accruals” basis so she could display the incoming revenue as soon as we got an order.  But, our expenses she recorded on a “cash” basis, meaning that she would only record an invoice we owed if we have the money in the bank to pay it.  The result was a near-disaster for our firm.  After too many months of making business decisions that were not based on a real view of the company, an internal check-and-balance process raised a red flag and ultimately the truth came out.  Her desire to only report good news had resulted in us digging a debt hole so big that we were lucky to be able to climb out.

I have since become much more skeptical of people who only speak of good news.  My antenna go up when someone displays the Pollyanna Principle.  (Not sure of what that reference means?  I’m dating myself but go back to look at a 1960 Disney movie called “Pollyanna” and you’ll see what I mean).  One thing about positive thinking that is not obvious but can be terribly damaging is that every time you say “Everything is great” when it really isn’t, you invoke the negative in everyone who hears it.

Don’t measure the results!  They might be terrible!

I’ve always been mystified by this but it’s not rare.  Recently I watched a volunteer organization consider one of their charitable programs and some members were bold enough to ask what the impact of this long standing program was.  Well, no one had any empirical results so naturally the idea of surveying to produce those results popped up.  You’d think everyone would want to know the answers, right?  Not so much.  The proposal to measure the impact of the program was soundly defeated.  Someone actually said, “What if we find out that the results are terrible?  Our donors might find out that they’ve been funding a program that doesn’t produce positive results!”  Sure, that sounds awful, but I can’t imagine that it’s more awful than having those same donors find out that the results could have been measured but ultimately weren’t and the program still didn’t produce the results that were expected.

No result + Good excuse = Result

This is so prevalent, I doubt many people notice when it happens.  Someone will not produce a promised result.  Perhaps the project came in late or perhaps it went over budget or perhaps a client has complained.  Over and over I see people saying “Oh, yes I know that but you see, it was raining.”  Then they expect that I will interact with them in the same way as if they had brought the project in on time.  Really?  The formula is, in fact: No result + Good excuse = No result + Good excuse + Me being irritated with you.

Some people get so caught up in making sure they can lay the blame for results on anyone but themselves that they don’t notice that there usually isn’t something pointing a finger at them to lay the blame at their feet.

Ever had a 3 year old who, when you walked into the kitchen immediately says “I didn’t eat the cookie!”  You look at them quizzically because they’re answering something you didn’t ask.  But, now that they brought it up, you’re suddenly really interested in how many cookies might be missing.

It’s more productive to focus on an action plan of how to turn your No result into a Result.

Project managers come into contact with people who espouse these practices all the time.  It can be a big challenge because at their core, project managers are usually all about becoming more effective.  But being committed to improving performance may mean some of those project managers will encounter PC-based resistance.  Producing empirical evidence about a project can be met with belief-based rhetoric.  Several years ago I was working with an organization about creating a portfolio prioritization process.  The worked spanned several months and the people involved were almost all quite senior in the organization.  When the resulting formulas and project evaluations that the participants themselves had come up with were presented, there was tremendous resistance.

“My project can’t be priority 55, said one.  It’ll never get done.”

“It’s your own evaluation of your project’s importance that has it be priority 55,” I replied.

“Then the formula must be wrong,” they answered.

“But you signed off on the formula being accurate in our last session, I countered.

“It doesn’t matter.  We have to change the formula so my project is in the top ten,” was the final edict.

I got through that session and many more like it by setting up a system of almost instant response to this kind of game-playing to reveal the real issue in this organization.  The challenge wasn’t what number came up in the portfolio analysis, it was can I have my project before my colleague.  That resulted in a process where the key participants could meet and ask for almost anything they wanted and we could show immediately how that would affect all the other managers in the room.  It was a contentious process and the doors were always barred under the principle that there are 3 things you should never see being made: 1) Sausages, 2) Laws and 3) The Portfolio Priority List.  Still, contentious or not, it got the job done.

Project Managers also learn that there can be a “kill the messenger” practice that can produce terrible results for them personally.  It’s not enough to just show empirical results and say “voila!”  You have to deal with all the human personalities of what people expect.

You may not want to be completely politically correct but remember there can be real-world impact from just telling the truth.  So, as you think about how politically incorrect you’d like to be, think about these tips:

  • Just because the real news is terrible and that people really should be confronting it, if you spend a little more time to think of possible actions, that helps not only temper the bad news, it points people into the direction of taking action to correct it.
  • If you’re the project manager or head of the PMO, you manage the actual display. There are many ways to show real results that can leave people thinking more positively about them.  Alternately, you can do the opposite.
  • Blame is rarely useful. So you’ve found that there is a big problem.  Ok, got it.  To say, “And it’s all Bob’s fault!” brings your analysis from a place where you can be in action to make things better to a place where we are trying to sacrifice someone in the hopes the gods will stop it from raining.  Focus on action, not blame.

So, enjoy the political correctness of the election season.  I’m sure we’ve not seen the best of it yet.  And, in your projects, stay on guard for it!

Technical Alliances, the good, the bad and the ugly

I’ve been wrapping up our renewals of two of our key technical alliances at HMS Software this week and it has me take pause to think about the different aspects of how these partnership works.  alliance.jpgI’ve been most recently working on our Microsoft and Oracle relationships.  We’ve had a technical partnership with Microsoft since 1995 so we’re at 21 years on that relationship.  With Oracle we’ve done 19 years as we started our formal relationship with them in 1997.  That in itself is remarkable.  That we would have formal ties with any other company for over two decades speaks to the longevity of the three companies involved and their mutual interests.

Each of these two alliances and the others we’re involved with have different elements but as you look at them, there are a few truisms that are worth sharing.

What are you in this alliance for?

If you’re tying your organization to another for your hoped-for benefits, it’s good to look beyond the partner brochures and be clear what you’re hoping to get out of it.  I don’t have any illusion that anyone at Microsoft wakes up in the morning and says “I have to make HMS successful today!”  Don’t get me wrong, it can be prestigious to have a 20 year link with a company like Microsoft but I’ve met with many entrepreneurs like myself who spend some money and a lot of time and effort to become a Microsoft partner and then complain that Microsoft isn’t giving them the 20 leads a day they expected.  “Did you ask anyone at Microsoft if they intended to get you those leads?” I’ll ask.  I’m quite certain that no one would make such a promise.  If you’re joining an alliance to get inside technical information or the partner logo for marketing purposes or for inside opportunities to work together, then make sure the other partner is aligned with that.

What are they in this alliance for?

It’s worthwhile asking yourself, “What do they get out of it?”  This can save you a lot of sleepless nights later when you’re wondering why you’re so involved and not getting what you want.  Some large technical alliance partners are looking for organizations on whom they can off-load resource challenges that they can’t handle themselves.  Others are interested in extending their reach through all of your contacts.  Still others are looking for you to be the “local” presence they lack as they focus on national or global marketing initiatives.  I remember asking someone at one of our alliance partners once why my partner listing was only for the Montreal area.  “That’s where your headquarters is,” they replied.  “But we sell software all over the planet,” I replied, “Over 90 percent of my sales are in other markets.”

“Oh.  We’re not really set up well for that,” was the answer.  Clearly that partner was looking for local presence to do installations or local support of their product, not collaborate on us both going to market together with both our products and theirs.

What is the real cost.  What is the real benefit?

All technical alliances have a cost.  Sometimes there is a direct cost to join a program.  The prices for different programs and what you get for them can vary greatly.  It can run from a few hundreds of dollars to tens of thousands of dollars to get on the “partner list”. But that is just direct subscription costs.  There is also often the cost of reaching certifications to comply with partner requirements, to attend mandatory and there is always a cost of the time to maintain the relationship.  It’s important before you start to think about what you’re really going to put in and what you expect to get out.  In our case, we invest in alliances where we are committed to put effort into the partnership and where we are reasonably clear about what we can expect to get out.

Am I constrained?

Some partnerships come with the caveat that you can only offer that partner’s technology or that you can’t offer certain kinds of solutions that might be considered competitive or which are not aligned with the partner’s own.  Recently there has been a push with some technical organization to “not invest if it’s not in the cloud”.  One of the potential pitfalls with some of these relationships is that if you do allow yourself to become constrained, you may find yourself highly dependent on the whims of your alliance partner.  It’s important to look at what constraints you might be agreeing to before you get started in the relationship.

Is this a fair trade?

One way of looking at new technical alliances is to see if it seems fair to both parties.  I remember a few years ago having invested an inordinate amount of time doing volunteer work for one of our alliance partners.  It was great for awhile as it afforded me remarkable inside connections with a partner that would be otherwise hard to reach into but the amount of time and money that had to be put into the arrangement eventually seemed unfair to me.  We changed the status of that relationship and everyone kept on much better terms.

Don’t promise what you don’t have

One pitfall I’ve seen often with people in our industry is that someone feels so strongly about getting the alliance established that they over-promise.  This can result in people actually changing their business in order to satisfy what the alliance partner’s expectations are.  I’ve seen organizations start a new sales group to try to sell an alliance partner’s products and services even though such sales weren’t a core part of their business in the past.  I’ve seen organizations change their product to adapt to only what aligns with the alliance partner’s products.  I’ve seen organizations stop lines of business because they perceived a conflict with their alliance partner.  It’s important I think to come to an alliance clear about what your business is and what you’re prepared to invest.  If that doesn’t work for your alliance partner, you should perhaps think about how important that alliance is to you.

Who expects what?

Finding out the expectations is key before you make a strategic decision to align your business with someone else’s.  Are they expecting you to do the marketing or are you expecting them to?  Are you expecting they will co-invest in development activities?  Are you expecting they will provide you technical expertise?  Are they expecting you will become their local representative?  Take the time to figure out the rules of the game before the game gets underway.

Is this the only path to what I’m looking for?

I have seen numerous people start on some technical alliance track only to find out it was the most complicated method of getting what they wanted.  A few years ago an entrepreneur approached me for advice on how to enter one of the alliance programs HMS is a part of.  That seemed like a disconnect for me between the effort required to join the program and the size of the entrepreneur’s company so I asked what they were hoping to get out of the relationship.  “The free software,” he replied.

So, I pointed out that if he had to spend all the money on the partnership just for that it wasn’t exactly free and, moreover that the alliance partner in question had numerous small-business programs designed for his size of firm that were primarily for getting access to their software at 10% of the alliance partner price.  Using one of those programs was what they decided to do.

Things change

It’s the software business.  Things change.  Sometimes they change very quickly.  You have to keep up with the direction your alliance partner is heading and while you may be disappointed, don’t get too frustrated if one day the long term alliance goes its separate ways.  Perhaps the alliance partner finds you competitive or perhaps you find the alliance partner is headed to technology that you don’t embrace.  Or, maybe you’ve become so darned successful out of your alliance that you need to renegotiate it to keep it equitable.

Alliance Partner programs carry enormous value to both parties when they work well.  We’re delighted about the alliances we maintain 1plus1equals3_300x165.jpgand we’re very proud of some of the long term relationships with other organizations that serve to benefit our joint clients.  In the end, isn’t that what these alliances should be about? Making 1+1=3. 

 

Old School

“Hey man, that’s old school,” said the person at the next table over from me at Starbucks.

fountainpen_300x225.jpgI looked up to see who he was talking to.  To my surprise, he was looking right at me.  The young man looked like he was studying for college.  There were text books and an iPad in front of him.

“Old school, man,” the young man, repeated pointing at my hand.

I was holding a fountain pen and making notes on a yellow lined pad.  Now I knew what he was talking about.  To be fair, there was also an iPad on my table held open with its Bluetooth keyboard but it was the pen that had caught my neighbor’s attention.

“Yes, I often like writing with a fountain pen,” I smiled.

“Why?” he asked.

“It makes me write slower,” I said.

This caused a look of confusion on the young man’s face that he hadn’t seen coming.

“Slower?” he parroted.

“Yes,” I replied.  “I find that if I write with a fountain pen, I’m obliged to write just a little bit slower and when I write slower, my brain seems better able to articulate its thoughts before they end up on paper.”

This was clearly a concept that my Starbucks tablemate hadn’t ever considered and it was so foreign to him that I could see he was really thinking about it.

I went back to my work and I left him with the thought.

I bring the conversation up because in today’s instant gratification, real-time entertainment, miniscule soundbite world, we have a tendency to work faster than we sometimes should.  This is mostly invisible to us because we live in it every day.  It’s like water to a fish.  We see it, they don’t.  They just live in it. But, we are pressed every day for faster and faster and faster results.  “Time to benefit”, “Time to market”, “Time to payback” are all popular concepts and prospective clients approach our firm all the time to find out how quickly they can deploy the enterprise timesheet or enterprise project system they’ve selected.

Going fast is not always the best plan.

Our staff try our best to have clients make a considered decision and to walk through the business processes that the prospective client is considering changing.

It’s not uncommon for me to have a conversation with a prospective client who says “We need to get this done” and when I ask for more details on “this” find that the organization hasn’t really considered the ramifications at all.

A few years ago, I was called into a large defense contractor by one of the largest publishers of project management software (I won’t mention the names to protect the guilty).  I was to be the “subject matter expert” referred to by my acronym: SME . You know people think this is important when they say pronounce the acronym like it’s a title.  “This is our “Smeee”.  I was very proud of myself for not laughing.

So, there I am, the Smeee, and as I sit down, someone literally hands me the end of a projector cable, leaving me very confused.

“What is this for?” I asked.

“So you can demonstrate the software,” the head of the PMO replied.

I had no idea what they were expecting me to show them but they were sure in a hurry to see it.  We hadn’t even gone around the table for introductions (except to point out that I was the Smeee).

“Um, maybe we can do it at first with the lights on,” I said.

This at least got people to laugh and then I insisted on someone describing what the actual problem was.

“We need your software installed and running right away,” was the answer of the IT specialist.

That made my hosts, the software publishers, very happy. They sat up even straighter in their chairs and looked at me expectantly.

“Sure, but that’s a solution to something,” I replied.  “Before we talk about how long it will take, perhaps we can talk about what you are trying to accomplish.”

The head of the PMO took up the challenge and, speaking as though I was rather slow, started explaining what their problem was.  It wasn’t so much of a problem statement as a description of how project data flowed through their system and I stood up, took control of the white board and started drawing it out.

The software publisher people looked unhappy.  They thought they were about to get a purchase order and instead we were doing flowchart diagrams on a white board.

I paused at each new tendril in the flow to make sure we got all of it on the board.  Most of the room participated in some way to make sure we got it right and once they were involved, the process moved quite quickly.  As often happens in these kinds of exercises, some people including the head of the PMO learned things about their own process they’d never known before.

It took almost an hour before we’d diagrammed everything we needed and the problem was apparent.  There was a bottleneck that had been created years ago to make sure that the Finance department and the Project Department both got data but the way it was delivered was in a complex movement of data through systems that were only used to massage the data for each party.

This bottleneck occurred in the section of the white board we’d identified as part of the Finance Department.

“Who speaks for them here?” I asked.

There wasn’t someone from Finance in the room which interestingly was where the heart of the problem was occurring but the head of the PMO had some inertia now and picked up the phone.  Five minutes later we had a senior Finance manager in the room.

“Do you recognize this part of this flow diagram?” I asked.

To their credit, they did and they knew more than anyone else in the room had known about this particular area.

“Is there some reason we couldn’t feed the source timesheet data for this to you in the way that you’re getting it now and simultaneously to the Project group in its original format?” I asked.

“None at all,” the Finance person said with confidence.

“Ok,” I said, “so, it looks like if we were only able to get all your sub-contractors to use the same timesheet system you have internally, then you could get everything you’re asking for instantly from the same source.  That would be a fraction of the cost and effort of anything else we’ve discussed.”

Now the software publisher representatives were decidedly unhappy.

“That would be impossible,” said one of the project people.  “We can’t impose that kind of requirement on our sub-contractors.”

“That’s not exactly true,” said the Finance invitee.  “I work in contracts and I can assure you that we have a clause in every single sub-contractor agreement that says they will use our internal systems if we request it.”

The meeting came to a close quite quickly.  We’d been speaking for almost 4 hours in a meeting that they thought would be software demonstration lasting 90 minutes.  Not one person left early.

One of my software publisher hosts was decidedly unhappy but his more senior partner told him that he shouldn’t be.  Selling a huge package of software that wouldn’t have solved the problem would have been ultimately the wrong move, he explained.  I appreciated the support.

The happiest person in the room was the woman who’d tried to hand me the projector cable at the beginning of the meeting.  She was able to isolate the true cause of her difficulties and discovered that she already had the tools for fixing it.

It was a day when I didn’t make any money but trying to make money in that situation would have cost me more in grief and upset than I’d have made in profit so I was satisfied.

Sometimes, going just a little slower can produce the best results.

Creeping Scope

No, I’m not talking about the new vine on your deck trellis.  I’m talking about scope creep. scopecreep.jpgIt’s every project manager’s nightmare.  The project starts off at a manageable modest size and in the blink of an eye, it’s a beheamouth of unmanageable porportions.

In one of HMS Software’s first ever mandates back when we were just getting started, we had a client who asked us to configure their project management system with multiple baselines.  This was unheard of in project management software of the day so we had to do some modifications to accommodate the request.

“Why would you need more than one baseline?” we asked naively.

“Ah, you don’t know the ways of the project management world,” our client informed us.  “There is the original-original baseline.  That’s the one we make when we first create the project.  Then there is the official engineering baseline.  That one includes any changes we’ve made to the original-original baseline over the term of the project that the head office has approved.  Then there’s the internal engineering baseline.  That’s the baseline that engineering is actually working against because they know the official engineering baseline is a fantasy.  Then there’s the expected baseline.  That’s the baseline that will become the new official baseline when we can propose it to head office and get it accepted.  That’s the baseline that the engineers project will actually happen.

Depending on who asks, we need baseline-vs-actual reports for any of those four baselines.”

We were stunned.  But we did what the client wanted.  While we worked on the deployment of the project system, there was a particular project that came up for head-office review.  It was a technology project that had been originally authorized 4 or 5 years previously.  The original-original baseline had been $4,000.  The actual was close to $4,000,000 (No, that’s not a typo.  The original budget was four thousand dollars.  The actual spent was close to four million dollars.

The project was cancelled.

Over the years we’ve encountered many companies with similar methods which attempt to control scope creep.  Here are a few thoughts on how to keep yourself out of the creepier side of scope.

How did we get into this mess?

People almost always get into these problems with the best of intentions.  In my own office, when this occurs it is usually because we are too responsive for our own good.  We’re trying to satisfy the client before determining if just answering today’s request with changing something is healthy for either of us.  Here are some of the most common ways people get scope changes creeping into their project:

Insufficient Scope

It’s obvious to say but some people just don’t look at everything involved when they scope the project.  Did you think about training?  Did you think about the links to other systems?  Did you think about fixing inevitable problems after delivery?  Did you think about risk?  Did you think about all the existing systems that are affected?  Did you think about the functionality in the system you are replacing that you don’t use but that someone else might need?

Taking your time to make sure you allow for all of the permutations of what you’d like to create is key.  Working with your vendor to see what else they can see from their perspective is key also.

Not including all the relevant parties
It’s a classic project management error that can cause significant scope creep.  A team starts working on the scope for a project but makes a wide range of assumptions for others who are not present and who are not consulted.  Only as the project nears completion do those people get involved and suddenly they have a lot to say.

Not walking the business flow from beginning to end
Short-sightedness in creating scope is also a common issue.  The project team identifies a function they desire but they don’t walk through all the implications of that function.  As a vendor, we often have to do that type of walk-through and it is common to unconceal a plethora of issues that no one thought about.  In some cases we find that the request actually contradicts other functions that were requested.  In other cases we find the request doesn’t deliver the result intended because of what happens later in the workflow.

Not associating changing functionality to a business requirement
I’ve written about this before but it is a common challenge.  Project team members make a series of requests but don’t pause for each one to determine how that request will affect the business.  We’ve taken the position with many mandates that each request in the scope must relate to some business purpose else why would we do it at all?

Thinking more of “how” rather than “if”
This takes some culture change in many companies.  I consistently ask our staff to justify a requested change from themselves or the client not just with how to do it but whether we should do it at all.  For many years I would be faced with a request and the answer, “Because the client wants it” as the answer to, “Why should we do that?”  Now my staff challenge clients themselves to ask what the purpose of the request is, to point out how that request might affect other elements of the project and determine if it should be done at all.

Being determined to do it all immediately
Some organizations have a challenge going through a project approval process and, as a result, they try their best to go to the money well a single time rather than making a phased approach.  Our experience shows this often to be a mistake.  Once a system is in use, new requests for changes from the client are almost guaranteed.

There are no doubt a hundred other causes of scope creep but you’re probably asking yourself if there is light at the end of the tunnel.  Is scope creep inevitable?

It doesn’t have to be.

How do we avoid getting into trouble?

Here are a few ways that organizations can avoid or mitigate scope creep.

Start with a commitment to avoid scope changes
Sound obvious?  It’s sadly not.  Many organizations avoid talking about scope creep at all given how little it’s liked.  As a result, those organizations have few tools and techniques in place to avoid the issue.

If you articulate your determination as an organization there are a few things you can put in place that have an almost immediate effect:

Include those affected
If you make a conscious effort to include those who may be affected by the project, you have a better chance of hearing what they need and managing both their objections and expectations long in advance.  This can have a dramatic effect on how many changes get requested later.

Review scope before approval
A formal review of the statement of work by all those parties we just talked about is a good place to start to find any holes you didn’t expect when you wrote it in the first place.  The review process must have a method for everyone to comment and for those comments to all be resolved before moving forward.

Make an allowance for what you don’t know
Making a contingency budget will allow you to deal with small scope changes without having to go back to a re-scoping exercise.  How much contingency you set aside is highly dependent on the amount of uncertainty or risk that you’re confronting in your project.

Monitor scope changes
If you can’t measure something, you can’t manage it.  So, set up baselines or other measurement mechanisms to determine if changes are occurring.  Those baseline measures will allow you to determine the size of any proposed changes too.  Whenever you do a change in your official scope, don’t erase the original, just make sure you reset a new baseline so you can start measuring against that.

Monitor and set reporting thresholds
Along with monitoring goes making a determination that it’s time to pause and relook at  your scope.  In our projects, we always know there is a small amount of contingency available and we set our own thresholds to take that contingency into account.  It’s important to set the rules for what your thresholds are before the project starts so everyone is aware of how much scope change it’ll take to make the project pause and regroup.

Make sure change requests serve a business purpose
I’ve talked about this before from numerous perspectives.  Often requests for changes will arrive in a project for purposes that are not associated to business value.  Or, the changes may conflict with other functionality that is associated to business value.

Many requests are often about familiarity and comfort
One of the most common types of change requests usually has something to do with familiarity or comfort.  The client looks at what has been delivered and says “That doesn’t look like what I’m used to.”  This can be frustrating when the entire point of the project was to do something new.  This typically means that whatever the legacy system or building or mechanism was is known to the client and what you are now showing is unfamiliar.  You need to be able to categorize change requests and their value or purpose so the client can make an informed decision about what they are asking for.

Think in a more Agile fashion

Finally, it’s popular to talk about Agile in software circles these days but I’m really referring here to the Agile concept rather than its entire methodology.  Agile at its core means doing things in phases.  Whether you call your phase a “sprint” or a “wave” or a “phase” or our “next bit” is less important than the concept of working in small incremental parts.  We have had our best success when we deploy not the most we can create but the least with full knowledge of both ourselves and the client that we won’t be done.  The sooner the client is using the software in real-life, the quicker we are to get feedback that’s relevant to how they function.  Our past experience indicates that no matter how much time we spend scoping the requirements, once the system goes live, we’ll get new requests for changes.

If change in scope is inevitable, the best way to avoid unexpected scope creep might be to plan for it from the very beginning.

 

It’s about the hole, not the drill

drill.jpgI’m in the software publishing business.  I should be all about selling you the tools.  It’s not about the result you want, it should be about the result I want… but that’s never been the way I’ve gone about business.  So this article is about the result, not the tool.

 

I came across an interesting expression recently.  A software salesperson was talking about delivering the entire solution to his client.  “We don’t sell drills.  We sell holes,” he said.  It’s a great analogy.  Many people (me included) have gone to the hardware store and window shopped in the power tools department while wondering what project I could possibly think of which would justify buying this great power tool.  But applying this logic makes as much sense in the do-it-yourself world as it does in enterprise software systems.

If you don’t have a problem, you don’t need a solution.

Just as no one should go looking for a drill unless the problem they’d like to solve is to make a hole, no one should go looking for enterprise software unless it solves some problem.  Now if you’ve got a problem that deploying enterprise software will fix, the next thing to ensure is that what you are buying will deliver the solution you need.  That’s often a lot more than just buying the software.

Deploying an enterprise system is a complex challenge so the payoff has to be worth the effort.  In today’s world of global project teams, one of the most common things to do is to divide the tremendous effort of an enterprise system deployment.  While this can give us economies of scale in using teams which are highly trained in their aspect of the project, it also holds the risk of overlooking aspects of the project in highly risky ways.  This risk is compounded the more physically and organizationally disconnected the different teams are.

Let’s take a look at the most common elements of an enterprise systems project.

What’s an enterprise?

First of all, what do I mean by enterprise?  I’ll take a definition that should work for almost everyone.  “Enterprise,” in this context, means any project which will impact how the entire organization functions.  I’ll say this is true for any organization.  Implementations that qualify as enterprise implementations aren’t just about how many users but how much impact they have.  So, updating our virus scanning software from vendor A to vendor B probably wouldn’t qualify.  Changing our finance system from one vendor to another almost certainly would qualify.  The implementation of project scheduling software on the desktop for a handful of users likely wouldn’t qualify.  Centralizing our project management and using a centralized enterprise project management system probably would qualify.

Okay, so if that’s an enterprise project, what are the most common elements of a deployment of an enterprise system?  In our offices the most common experience is deploying enterprise timesheet systems, such as our own TimeControl, or enterprise project management systems, but these elements will be common to almost any enterprise system implementation.

Bits and bytes

First let’s tackle the most fundamental building blocks of software: the technical architecture.  These days we have to divide our thinking based on our decision to go with an on-premises deployment or an in-the-cloud subscription.  I’ll leave the wonders of choosing which of these is best under which conditions for another day, but here are some of the basics of what we’ll have to think of in each category.

If we’re going with an on-premises installation, we have to think about what hardware we’ll use.  What are the hardware requirements for memory and CPUs?  Will we use physical servers or virtual servers?  Will we use dedicated servers or shared?  What kinds of servers might be required?  Will we need application servers, security servers, web server servers?  What about load balancing, disaster recovery, and backups?  Will we need cold or warm backup servers?  Whew!  But we’re not done!  What about the database?  What are the requirements there?  How about support for our existing security, application, and database architectures?  What about support for browsers, browser versions, and mobile devices?

Once we’ve got all those questions answered, we have to handle the issues of installation, test, and production environments, and then system health and monitoring once the system is up and running.

If we’re going with an in-the-cloud subscription implementation, we still have questions to answer though they may be very different questions.  Which online service do we use? Do we go with a dedicated installation or a multi-tenant service?  What about security?  Can we integrate with our own authentication?  How do we handle disaster recovery with the subscription service?  Where is the data physically located?  Does this present legal issues for us?  How about support for our internal browsers and mobile devices?  How will we get our data out and how can we connect with our internal databases or other external SaaS (Software as a Service) services to integrate functionality?

Out of breath yet?  When we’re talking about an enterprise system, these questions and more are on the agenda. If we shift this part of our project off to our highly trained technical team, they might start to think of this as the scope of the entire project, when this is just the construction of our drill, not yet the making of the hole we need.

Configure me!

Aside from just getting our system working, there is also applying the functionality within that system to our specific problems.  I’ve seen Project Server deployments where the client gets Project Server up and running and then realizes they have not allocated any funding for creating workflows, learning how to prioritize their portfolio of projects, or learning how to make a single report.  Just like Systems Analysis 101 back in college, we typically start this part of the implementation at the far right side of a white board as we ask the business people who have the actual business problem what “outputs” they’ll need.  I’ve spoken of this before in other writings so I won’t belabor it here, but the outputs should ultimate be business decisions.  To make those decisions, what reports, analysis, and, ultimately, data inputs do I need?  We work our way from the right side of the screen to the left and we end up with a list of all the building blocks we’ll need in the form of data elements, analytical calculations, and exports and reports that will need to be configured in the system.  This configuration exercise can take weeks or months depending on its complexity.

Often the types of resources we’ll need for this aspect of the project are a combination of business analyst and system expert, and it’s common that while these people may be highly skilled in the functionality of the system being deployed, they are not as skilled in the technical architecture.  That makes having disconnected teams for two critical elements of the system quite common.  The less these two groups communicate, the more likely it is that we’ll face challenges later.

It’s a process

It is impossible to deploy a new enterprise system and not affect the organization’s processes.  Even if you are abandoning one centralized enterprise system and moving to its competitor, processes will change.  In fact, if you don’t want your processes to change, then it is entirely possible that you don’t have a problem that needs solving, and herein lies yet another challenge.  When a person’s daily routine changes, it causes upset.  I don’t mean some of the time.  In my experience, upset at this type of change is a given.  This is true even when the process change will result in a better process!  So thinking about how the processes will change and working with those who will be affected is critical to the success of the project.  However, the very experts who are critical to designing this change in process are probably the same people who will be affected by that change, so this can be a challenging aspect of the implementation.  Usually, a skilled and experienced facilitator will work with the internal experts in guiding the change in process that has become possible with the implementation of the new system.  In our line of work, we see this challenge all the time.  “But the project managers have to do the timesheet approvals first,” a new TimeControl client tells us.  “That’s our process.”  When we explain that matrix approvals can allow project managers to do their timesheet approvals as part of a larger, more effective process, we get upset; pushback.  At this point, we have one of our most experienced staff work with the people affected to ensure that their concerns are taken care of, and that they are an integral part of how the process will change.

So the process people are probably not the configuration people or the technical people, yet if we don’t have this team planned for, all our hard work on the installation and configuration is probably not going to be deployed.  This team too must be part of our planning, included in communications and decisions made by the other two teams.

Training

“So, will we need training?” is unfortunately a question that is often asked last.  Some training may come through the process changes as that part of the project requires a lot of hands-on discussion, but what about the actual user guide of how the new system will work in more of a step-by-step fashion?  At one time, training was considered to be a critical element of software deployments and clients expected to put aside about 20% of the total budget on it.  But, with the changes in software costs and speed of installation, gradually that 20% became less and less money.  If we’re paying $20 per month per user for a system, should I put aside $4 per user for training?  I can promise it won’t go too far.  There are many online subscription options for training, but none of that will take into account the exact solution you’ve designed.

Trainers may come from the outside or may come from the configuration or process parts of the project, but they are often people who are specialists rather than the people who actually did the implementation work.  So even if you’ve put funding aside for this team (and I hope you have), you still need to make sure that these people know what the system they’re training people in is actually designed to do.  I’ve seen trainers arrive for training in an enterprise project and portfolio system and had them start explaining to users how to configure fields and set up workflow, only to have the users give a blank stare because the company had already done some configuration on their own and had decided not to do portfolio analysis at all in the initial roll out.  Do your trainers even know the problem this particular deployment is supposed to solve?  They should.

Thinking about training at the start of the project gives it the greatest chance of success.  The technical, configuration, and process teams can be putting critical data aside all through their sections for the training that will ultimately be delivered.  That means involving the training team early.

Roll-out/acceptance/culture change

If you were forward thinking and put aside the resources to initiate these teams and have had all of them working and communicating together through the project, then the roll-out of your new system is likely to go much smoother than it might otherwise, but don’t underestimate the resistance to culture change.  Having key evangelists available at the right time can be critical.  Also, will all these team members be packing up and moving on to their next project?  There will be a lot of system knowledge wrapped up in these people by the time the project rolls out.  I was particularly impressed with one of our clients early last year.  It was the IT department for a large financial organization. One of the concerns we surfaced to the key technical user who was evaluating the software early in the project was “who will be the administrator once you wrap the project up?”  “I will,” he said.  He was true to his word.  His skills and knowledge evolved through the multi-month deployment, which was a great success, and he remains the key administrator still.

Wrapping up

There are a hundred other things to think about in how to make sure your teams are communicating and working as part of a larger goal, and we’ve talked about only a few.  Hopefully it is making you think already about your next enterprise system deployment.  “What about documentation?” you might be thinking.  “What about technical support?”

The key thing to remember is this:  When you are planning an enterprise system deployment, you have to expand your perspective to include not just the installation effort, but also the delivery of the completed solution.  Make sure the hole appears just where it should in just the right size, right depth, and right angle.

Note: A version of this article was published by Microsoft on TechNet.

Charge Code Common Sense

Common_Sense_300x140.jpgI’m often asked to help organizations define their charge code structure, either for their project management system or their timesheet system.  While it’s true that every organization is different and different needs result in different types of charges, there are some common practices we’ve found over the years that are universal.

Ask less, not more

No one likes bureaucracy, so the more complex a charge code structure you make, the less likely it will be that people make accurate reports.  Imagine, for example, that I make a list of 10,000 charge codes in a long flat list to choose from.  You might have to scroll for an hour, examining each possible entry in a drop-down list before you’d find the exact right choice for this particular timesheet or project update.  Then you’d need to scroll through the rest of the list to make sure you didn’t find something that wasn’t just a little more exact.

Let’s not be silly.  No one will do that.  They’ll take the first entry that seems reasonably close and choose that.  Failing that, all hours will ultimately end up in the infamous category of “999:Miscellaneous”.

So make your list simple.  Ideally, it should not require scrolling at all, but should be visible on a single screen or perhaps with one more click.  That means that you’re only choosing from 20-30 possible options at most.  In this case, less is more.  In TimeControl we use hierarchy to allow users to see a very complex list in a drill-down fashion but this too can get out of control.  I remember seeing a draft proposal for a 10-level charge code list for a software development company.  “They built the space station with a 4-level list,” I informed the head of the PMO.  In the end, the company went with something a bit simpler.

If management is determined to get much more detail, remind them that it is better to get more accuracy and less detail than more detail and less accuracy.

Don’t ask what you know already

I’ve seen many charge code structures where there is an identical charge code for each department or each project.  Yet, if people are already being asked to choose the project and we’re doing an entry for meetings for example, then I know that the line item must be “meetings on this project” so why pollute the charge list with multiple meeting items?

The same logic holds with departments.  If we have a list of employees who belong to each department, then we already know what department they’re in.  Why pollute the charge list with “Sales department meeting”, “Technical department meeting” and, “Marketing department meeting”.  Just make one item called “Meeting” and we can deduce from the employee’s department and the project they’re on what the meeting was for.

Be resolved to better resolution

Picking an appropriate level of resolution for your project and your timesheet is a common challenge.  Think about what level you want to manage things in with these conditions: 1) There needs to be more value in the data than in the time to collect it, so if you spend all day reporting on your day, how will you actually get anything done?  2) Work at a level that you’re prepared to make decisions on. 3) The more complex it is to enter, the less likely you are to get accurate data. 4) When possible, get everyone working at the same level of resolution so you’re not managing one group in tasks that are 10 minutes long and another in tasks that are 3 days long.  For many people, being able report 3-5 lines of detail for a given day is plenty of detail.

Condition your data

Some people will make the end user answer the same questions over and over.  For example, we’ve seen systems with a column for “R&D” meaning that this charge is or is not a charge eligible for an R&D tax credit.  But we should be able to associate the eligibility to the task itself rather than each line of each person’s timesheet.   Moreover, what would I do if some users thought that it was eligible and some users thought that it wasn’t?  This likely scenario also plays out in examples such as, “Design-eligible for R&D” and “Design-not-eligible for R&D”.  This doubles the number of charge codes for no return in value.  Just have someone in R&D flag each drop down value as eligible or not and you won’t have to keep asking end users to try to figure it out each week.

Hierarchical

Better project and timesheet systems allow a hierarchical display of data.  If you have no choice but to have a lot of possible choices, then building a hierarchy can make a lot of data easier to swallow.  Think of simple non-scrollable list of 5-10 items at maximum to choose from at each level.  And don’t be tempted to make dozens of levels.  Making a 3-4 level hierarchy should be able to cover most options.  After all, 10 items per level in a 4-level system is 10,000 possible charges.  Does your project really need to be more complex than that?

Show me less

The fewer questions and choices you give your users, the better off you’ll be.  If there is anything you can answer in the background then try not to ask it of users on your timesheet.  The goal is not to collect the most data possible, it’s to collect as accurate a picture as possible, and you’ll do better at that if you insulate the end users from data, questions, and options that make no difference to them.

What will you do with that data?

I’m often told by middle-management types that they need “much more detail” than I’m suggesting and my response is always the same: “What will you do with it?”  The purpose of gathering task-based timesheet data is to make better business decisions, so I’ll often ask those middle managers what business decision they’re not able to make now that they think they’d do better at if they had more detail.  When you start to look at information that way, you find that you probably need less of it.  It might be enough to find out just the total number of hours spent in meetings or in transit or in overhead tasks than to find out what every one of those tasks was.

Drill deeper… but only when you must

When you start to do timesheet analysis to figure out where your hours are all going, you are bound to find some disproportionate results.  Where you find an unusually high percentage of hours that defy expectation, drill a little deeper.  But not too deep. Add one more layer of detail for that charge and give it a few weeks to see what data you get.  The temptation will be to expand a single charge code like “meetings” into 50 new charge codes with every possible type of meeting that could occur.  Try resisting this temptation and instead change that 1 charge code into 5 or 6. If you don’t get the detail or you still have disproportionate results, delve a little deeper.

Keep a clean house

Charge lists have a tendency to increase in size but never decrease.  It’s a good practice to review them on a regular basis and eliminate bloat.  If you do, you’re more likely to continue to get more accurate information and be able to identify areas where you’re losing time.

Charge code management—whether it is for your project schedule or your timesheet system—can make the difference between an efficient system from which data can be counted on or a system with too much definition and not enough accuracy.  When you design your charge code structure, we recommend starting with less, not more.  It’s much easier to add more detail later if it is required than it is to undo more detail and make it simpler for overwhelmed users.

Note: A version of this article was written for Microsoft’s TechNet

© 2016 Chris Vandersluis

Business Analysts and Vendor Specifications

business_analyst_300x172On a regular basis around HMS we get specifications from clients of what they’d like to have our TimeControl timesheet do for them.  It’s a necessary part of the evaluation process for a client to find the right type of timesheet for their particular business challenge.

The problem is that the language that the specifications are put in are rarely those of business.  Most often the specifications are made in terms of features as in “the timesheet screen should have a button that when pressed, does this”.  In the context of a solution provider, it is as though the client is writing their description of the solution without identifying the problem.

This has been a challenge even internally when clients try to explain to their own IT department what they need developed for them.  Instead of identifying the business challenge that they are facing, they leap forward to try to describe what the solution the IT department should write.  The newly popular role of Business Analyst was supposed to fix that.  BA’s (I know, I know, everything important is always referred to by its acronym!) were expected to interpret the requests of the client and articulate them to the IT department in more technical terms.  BAs were expected to the Tower of Babel that instantly interpreted client-speak and turned it into programmer-speak and vice-versa.

But BAs have had challenges too.  They too often arrived after the process of making a request to IT has already been underway for some time.  The “solution” is already being drawn up and the technical staff including the Business Analyst are then enticed down a path of speaking of the project in terms of what features the client has invented.

If we look to the International Institute of Business Analysis (IIBA), they define a Business Analyst as “a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”(1)

And, where do these features of the client come from?  Often enough, from existing software or systems they are already using.  Perhaps it’s an old legacy system which is being retired or perhaps it is something they use in their personal life and they’d like that feature to come into their business application.  Very rarely, is the feature the result of thinking of the business challenge facing the organization which evolves into a technical request.

In our world here at HMS we get that too.  A spreadsheet arrives with 250 characters of text describing each “requirement”.  The reason for the feature is almost never apparent.  Often there are feature requests which contradict each other which indicates that more than one person has put their demands into the list.

Wouldn’t it be easier if instead of describing features, the client described their business problem?  Solution providers like us and IT departments who need to deliver a solution could then consider many possible solutions.  A Business Analyst who started in on the project at this point instead of much later in the proces would be able to consider changing a process instead of writing some software.  Perhaps there’s an online service that would help or some training that would fix an underlying problem.

Bringing Business Analyst thinking early into the specification process is almost always going to result in stronger answers to business questions.  Whether you have an official BA role or not, think about the business challenge and getting that articulated before you jump ahead to how you’d solve it.


(1) International Institute of Business Analysis (IIBA). A Guide to the Business Analysis Body of Knowledge®, 2.0 (BABOK® Guide 2). Cited in: Jerry Lee Jr. Ford (2010), UML for the IT Business Analyst. p. 2

Not all EPM Software looks the same!

Fresh Orange Among Green Apples, Isolated on White

Fresh Orange Among Green Apples, Isolated on White

In my office recently one of our most experienced employees came to me with a strange question.

“How do you know if something is a project management system?” they asked.

I opened my mouth to answer then paused… for a long time.  The answer is not obvious.

In the early 1980s the first critical path scheduling packages became available for personal computers.  In fact, I find it interesting that history shows that critical-path scheduling software has been one of the first commercial applications published in each wave of computing starting back with the first commercial mainframes in the 1960s.  My start in the project management software industry dates back to the early 1980s though and we would have used the terms “project management software” and “critical-path scheduling software” synonymously.

In 1983 if someone had shown me anything but a critical-path scheduling system and asked if it was a project management system, I’d likely have shaken my head and said no.

The most popular project management tools like Microsoft Project or Primavera are, at their core, critical-path scheduling systems and we still use the terms project management software to describe it.  So if someone were to ask me “Is Microsoft Project or P6 project management software?” I’d feel pretty comfortable answering in the affirmative.

But what about accounting software?  Many accounting and ERP products do project budgeting and cost tracking.  Is that project management?  I’d have to say that it is.

What about document management products which allow you to manage documents and document workflow and make lists of outstanding issues.  Is that project management software?  It sure sounds like it.

How about your SharePoint or Oracle CRM which allows you to attach activities and resources to client initiatives.  Isn’t that project management?  It certainly could be.

How about contract management, timesheet management, workforce scheduling, material consumption and equipment usage management, and production value tracking?  Are any of these project management?  Yes.  Any of them could be.

Years ago I worked with a specialist in construction project management whose main tool was something that managed the pace of work of several trades simultaneously.  This single graphical report tracked carpenters and plumbers and electricians and several other trades.  This very experienced project management showed me how just managing the pace of work from one team to another avoided electrical teams arriving to an area before the drywall was erected and kept the plumbing team from overrunning the electrical team.  This single report for this particular type of project allowed this project manager to be remarkably effective.  Was that a project management system?  You bet it was.

To make matters more complex, we have both project management tools that make individual project managers effective and other tools which are more appropriate to the organization.  Enter “Enterprise Project Management” software.  To be fair, the concept isn’t that new.  The first project management systems in the 60s and 70s were all enterprise tools, though access to computer systems in general was much more restricted then for most organizations.

Like all good things, Enterprise Project Management resolves to a three letter acronym: EPM.  If I do an Internet search for EPM, though, I might find Enterprise Project Management.  I might also find Enterprise Performance Management, Enlisted Personnel Management, Electric Propulsion Motor, Exchange Permission Manager or any of about 40 more definitions.  Make sure you’re looking for the right one because a propulsion motor is unlikely to help you with project scheduling.

If we have difficulty defining a project management system, it’s certain that we’ll have even more difficulty defining what makes a project management system an “enterprise” project management system.

In the end, is it that important?

I’ve been known to say for some time that I always prefer to define the problem before we start looking for the solution.  Our office often gets calls asking for help deploying an “enterprise project management system” and inevitably I must ask about both what they mean by “enterprise” and what they mean by “project management.”  It takes a minute or two for some to get over having to explain themselves.  After all I have some background in project management and they’re certain that I must know what these terms mean.

Sometimes I find out that the “enterprise” is in fact a handful of people.  There’s nothing wrong with that.  I run a small company myself and no size is too small.  But not asking might have had me recommending software that was designed for company of 1,000 people, and while I’m sure it would look lovely, it would be a complete disconnect between tools and requirements.  Plus, the return on investment of such a deployment would likely be awful because of the difficulty in paying back such a disproportionate investment with efficiencies of a small team.

If you want to give advice on tool selection, not only is it important to get the scale right, it’s critical to determine what the business challenges are.

A number of years ago, I visited a very large power authority where we had built up a good reputation for assisting with deploying project management software.  During this visit, I met with the head of a new department who wanted to deploy “enterprise project management software”.  I sat with him and went through his requirements.

“How many projects do you have?” I asked.

“Ten to twelve at a time,” he answered.

“And how many tasks would you have in these projects?” I continued.

“Oh, it’s always the same.  Six tasks,” he replied.

“Six,” I repeated.  “So, we’re talking about 60-70 tasks to manage at a time?”

“Yes, that’s right.  It’s very complex,” he said.

“I understand,” I said.  “And how many users will be involved in managing these tasks.

“It would just be me,” he answered.

You can see this coming, I’m sure.   There was no critical path, no issue management, no document management, no resource leveling, no risk management and no cost management required.  All he needed was a visible guide to outstanding tasks for himself so he didn’t let something drop through the cracks inadvertently.  The amount of money on these projects was actually huge, in the millions of dollars, in fact, but the unique type of project meant that managing it was relatively simple.

“Why not just put them on a white board here in your cube? I suggested.  You could use some permanent marking tape to make rows for, say 15 projects and then use colored dry markers to update the schedule and it would be right in front of you.  You could use a red marker for example to make a note of important milestones and a green marker for tasks with a long lead time.”

He seemed quite perturbed and upset even that I couldn’t recommend a large enterprise piece of software to manage his projects.  He’d heard from others in the company that there were great enterprise project management packages out there and was sure I’d come to him with a recommendation of deploying one.

The meeting wound up shortly thereafter and I was sure I’d left an unhappy new contact behind.  To my surprise he called my cell phone a half hour later while I was on my way home.

“Thanks so much for the meeting,” he started. “I’ve already ordered a white board from the office supply department but if you could spare a minute, could you go over with me again which color I should use for which kind of tasks?”

Fifteen minutes later he had taken copious notes and was a happy camper.

It was a great lesson for me which I’ve carried to many more engagements.  I try to take that extra minute early in an engagement to determine what is meant by terms that deceptively sound like a universal standard.

Project Management software could be represented by numerous categories.  If we just start with the Project Management Institute’s Project Management Knowledge Areas we’d end up with:

Integration Management Cost Management Communications Management
Scope Management Quality Management Risk Management
Time Management Human Resources Management Procurement Management

It’s easy to imagine a variety of tools, packages and techniques for managing any of these areas, and, depending on the particular situation, any one of these categories could produce the most significant improvement in project management or project management across the enterprise.

Let’s say an organization has project communications challenges; perhaps its resources are spread across numerous time zones and countries and even companies. In that case, it would be easy to see how you could deploy Lync and SharePoint to make a huge improvement in communications.

If an organization deals with many sub-contractors on its project or if it has a large purchasing component in its project, then strong procurement management with a Dynamics ERP and SharePoint might make the biggest difference.

If the organization is complex or of larger size and the project challenge is prioritization and resource capacity planning, then perhaps Project Server is the fastest path to a return on investment.

Remember that staff person asking about how do you know if a particular package is project management software?  My answer was this: “Is it software?  Does it apply to managing projects?  Then it’s project management software.  Now go back and find out what the client’s project management business challenge is.”

Articulating your project challenge before deploying your project solution will always yield better results.

(c) 2016 Chris Vandersluis

Note: A version of this article was published by Microsoft on Microsoft TechNet.