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?”

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. In 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 5^th 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. I’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 and 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.

I 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.

Archive: May 25, 2016