Some of you out there in the world are probably familiar with the terms Capitalizing and Expensing.  In the world of software development, this expresses itself in these general terms:  If you are building new software or new features that add value in existing software, you can capitalize the costs.  If you are doing maintenance (fixing bugs, etc), then you expense the costs.  They are also terms that you tend not to think about a lot other than how to report costs to the Accounting and Finance folks.

Here’s another aspect of Capital we don’t always think about.  Physical assets that are Capital cost maintenance over time.  If you buy an office building, it requires maintenance.  If you buy a car, it requires maintenance.  The bigger the thing, the more maintenance it requires over its lifetime.  This is just as true with software.

The larger and complex a software project is, the more you may have in the following costs:

• Hardware: servers, desktops, network equipment, etc all cost money, must be maintained, and have to be replaced.
• Hosting: Hosting internally means costs within your data center- more servers, more cooling, more power, more floor space, more people.
• Code: Greater the size and complexity of the software, the higher the likelihood that you will have ongoing bugs that need to be fixed.  Also, you will have real costs attached to updating for security fixes, changes to the Operating System, to your web server, to the database, etc.  Also, some types of systems will require constant updates.  This is particularly true for software that emulates business or legal processes and evaluations.
• Training: Every new piece of software requires documentation and training for your users.  Adding features means revising training and updating documentation.
• Liability: Software stores data and has to handle data correctly.  Security flaws, calculation errors, data mis-entry, and more are all real areas where you (or worse, your clients) can end up with the wrong data in hand and making bad decisions as a result or receiving private data they were not meant to see.

These are all real costs you have to consider when building a new piece of software for your company.  Sure, you may be able to justify the build based on saved labor for the business, but what about when you add additional costs for maintaining it?  Does the cost still balance?

Another point to consider is are you staffed (and can you afford to be staffed) to support the product.  If you had to bring in consultants to build the software because your existing staff doesn’t have the bandwidth to build it, then you should tread carefully here.  Make sure to measure that your existing staff has the bandwidth to support the new product after the consultants are gone.

The biggest reason to consider this, though, is to keep yourself in reality.  Two of the biggest and most common problems in companies today are rising IT costs and shortages in IT resources.  Failure to consider, plan for, and allocate for the amount of work necessary to support IT projects after the project itself is completed is one of the biggest culprits that can be blamed for these problems.  Be sure you think through these post-development costs before you engage in new software development initiatives.

Here’s a fun but short comic on how to really nail an interview… or, alternatively, recognize when you’re really landed talent- and thanks to xkcd!

Marketing Interview

Ever bought a bag of potatoes at the store, brought them home, then in a few days find one bad potato in it?  Experience teaches you that you have to get it out of there quickly- not only because of the smell and the mess, but because it seems that the rot always spreads- soon the whole bag of potatoes are ruined if you don’t get the rotten one out quickly.

Project and Operational teams work like this.  I think we’ve all experienced a “bad apple” on a team.  Dealing with the one person who, for whatever reason, is doing a bad job, invariably seems to drag everyone down.  Your best performers will vary as to why they get worse at what they do- resentment over everyone not pulling their own weight, frustration at obvious incompetence, impatience with poor communication skills… the list goes on and on, but it always happens.  Not only does the poor performer not do well, but they drag down the team.

This is not just random observation, although it’s likely many of us have seen it, but it’s shown up in research.  Here’s an interview from This American Life Of Will Felps.  Felps is a researcher and professor at the Rotterdam School of Management.  His experiments with inserting bad apples into work teams showed that not only did bad apples damage work teams, within 45 minutes other team members would begin to take on the characteristics of the bad apple.  Everyone on the team’s work would degrade.

Another effect of a bad apple is that their presence is often seen as a challenge to your leadership.  Your failure to do something about bad performers reduces both the trust and respect of the rest of your team in you.  I’ve heard this said to me and of my colleagues more than once in my career: “If you/mangement/whoever can’t see that (insert bad apple here) is wrecking this project, you/they are an idiot.  If everyone else can see it, why can’t you/them?  If you can, why don’t you fix it?”  Or, here’s the worst one of all:  ”If you/they don’t care that (bad apple) is wrecking the project, then obviously you don’t care.  Why should I?”

I’m not saying can everyone who does a bad job on something, but the one thing you must do is take action quickly. Correct the behavior if you can; if you can’t, get that person off the team they’re screwing up and get them on to something else- either in your company or not, but get them out of there.  Too many times companies sit on their poor performers.  I myself have been guilty of this before.  The instinct is to give people a fair chance, but ‘fair chance’ does not get the job done.  Action does.  Take action to rehabilitate or remove your bad apples.  Don’t drop the performance of your entire team.

Transparency is one of the great industry buzzes to build out of the collaboration movement.  People talk and talk about becoming transparent to their partners, their clients, their cousin Phil… you get the idea.  It’s a good movement; transparency promotes information sharing, and information sharing leads to better decisions… or does it?

Transparency can be a double-edged sword.  There are aspects of any process that may be par for the course, but to an outsider, look like unmanaged, undisciplined chaos.  Watch any of the “reality show” series like Mythbusters or Junkyard Wars, where people build very complex things very quickly, and you’ll see what I mean.  The team that looks under control sometimes is not, and vice versa.

This is particularly true in software development, where developers often debate the hows of solving a problem until just the right detail shows up; where it’s hard to commit to a final deadline or even an order in which you will do things until the last detail shows up, where what appears to be small detail changes to the outsider can lead to huge changes in the software.  A good friend of mine refers to this process as “making the sausage”.  Most people love sausage; if they saw how it was made or what went into it, they wouldn’t be able to eat it.

So if transparency is so dangerous, why is everyone doing it?  Why shouldn’t we run from it?  Why aren’t projects falling apart all over the business world globally because of it?  The truth is that some are.  Like all tools, before you can use Transparency to its fullest potential, you need to understand what it’s for and what you are trying to do with it.  if you use it incorrectly, it will hinder rather than help.

Transparency lends value in two important ways:  it spreads useful information, and it builds trust between groups.  There are two key words there:  useful information, and trust.  These are actually very easy to apply here if you think about it:  information people do not understand is not useful.  People do not trust things that they do not understand.  Also, in the category of trust, no one trusts anything or anyone that surprises them in a negative way.

Drawing from this, we can apply a set of simple do’s and don’t’s to Transparency to make it work better:

• Do share anything that is a roadblock.  Never let people get surprised when your team runs into trouble.
• Do summarize wherever possible.  Keep things in terms that all teams understand.  Ditch jargon.
• Do be prepared to explain details, especially related to roadblocks.
• Do be prepared to rate the amount of trouble the roadblock really is- people fear the unknown; quantify it where possible.
• Do not share details for the sake of sharing them, unless you’re specifically having some type of true learning session.  Respect people’s limits in how much data that they can take on a time.  If you bury people in information, they’ll miss the important parts you share.  Make sure the most important details are always at the top.
• Do be prepared for that there will be times that too much detail comes out, and you’ll have to handle it.  A lot of people are problem-solvers in the business world.  That’s what we all do.  If you get too much detail in front of them related to a problem, they will want to dig into it.  This is a delicate balance, because often the time you take explaining what’s going on just contributes to delaying the solution and contributes to your frustration.  On the other hand, not explaining enough frustrates the people you are sharing with- and it can make them feel you’re hiding things from them.  This is one of the slippery slopes of Transparency where you can build stronger trust, or you can do a lot of damage.
• Do not make shared decisions in a vacuum unless you have no choice.  Once you open things up, you hurt trust when you start leaving people out.

There’s a lot of other things to consider, but the bottom line is Transparency is about building Trust.  Follow your instincts around building Trust and respecting people’s time.

My company’s CTO has a saying about building software.  He says that it’s a lot like making sausage.  There’s a level of detail you want to know in order to be happy with it- are you using quality ingredients, when will I get the finished product,  is the facility clean… and then there’s a level you definitely do not want to know if you don’t want to feel ill or ever intend to eat sausage again.  My grandfather owned a slaughter house; trust me, he’s right.

Something my company has been struggling with for years has been how much detail is enough for project reporting.  This has been even more complicated by the founding of our PMO.  Here’s a few of the issues you run into when the business folks look too deep into the project details:

• Reporting overhead:  the deeper you look, the more effort is put into telling others what’s going on by the managers who are supposed to be spending time getting things done.  If you pull away too much of their time, the project actually starts to fall behind- because you so busy looking at it that you monitor it to death.  At some point, you have to trust the project workers to handle the details that they gloss over in meetings.
• Knowledge transfer overhead:  this goes in part with reporting overhead.  The deeper a detail you look at, the more explanation goes along with it.  This is especially true in the IT world.  Some tasks and problems require a very in-depth technical knowledge to understand.  The deeper you look into them, the more background information and technical detail that has to go along with it.  All of that communication overhead pulls people away from the real work.  They are talking about doing rather than doing.
• Executive attention syndrome:  if the reporting goes deep enough down the rabbit hole on every project, your company’s leaders soon find themselves spending all their time drinking from the information firehose and not enough time actually leading.

The site has been “dark” for a while now as I’ve been involved in a lot of other projects (work, remodelling the house, being happy, etc).  While I’m not necessarily expecting to go back to my full blogging schedule again right now, you should see some new posts coming in the coming days (weeks?  months?).  Stay tuned folks!

Johanna Rothman posted recently over on her blog about Results versus tasks which I highly recommend.  I’ve writtten on this before myself here, here, and probably elsewhere, but Johanna offers a nice real-world example.  As a PM, manager, or any other insane  person, you cannot expect people to finish tasks if you are not explaining the results.  For that matter, I daresay you can’t project manage at all.  After all, how are you supposed to know if they’re done if you don’t know what the results are?  Can’t they come into the meeting and just nod and smile at you?  How will you know they’re telling you the truth?

You simply cannot manage what you don’t understand, nor can you delegate it or request updates on it.  Understand and manage to results, not to line items on a task list.

How many times has this happened to you:

A key task in the critical path of your project is completely out of control.  It’s not getting done, what is done is all wrong, and everything is late.  You go and talk to the person who is in charge of it, and you hear those fateful words, “I didn’t know X, Y, and Z about this project.  When was that said?”  You immediately go back to your desk and add that person to every project meeting to ensure it doesn’t happen again.  In your next project, you vow to not leave anyone off any meetings, because lack of communication causes problems.

Sound familiar?  It’s common in project management- and it’s also the wrong reaction.

How much homework do you do on who should be in each meeting of your project?  I’m going to suggest something that may be sacrilege to many folks:  overcommunication through meetings can damage your project.

Think about it:

• By including people in a given meeting who didn’t need to be there, you are wasting company resources and robbing other projects of available resources.
• By including people in a meeting who doesn’t need to be there, you reduce how engaged that they are in your project.  A few meetings like this, and you will completely loose their attention- which means that they’ll miss details later that you can’t afford them to miss.
• Worse, if they perceive your meetings to waste their time, they will stop coming.
• Even worse than that, their manager might pull *all his resources* out of your meetings rather than waste their time.
• People sitting in the meetings not paying attention will naturally set a bad example to others.  If others in the room are not engaged, your other team members will also become less engaged. 

What can you do to avoid these problems?  Simple:  do your homework before you hold a meeting.  If certain people do not need to be there, be sure to leave them out.  If they missed something that they need to hear, DO NOT tell them through sending out a project status report to the whole team- take the time to send them a note directly.  Trust me, your status report suffers from the same attention problem as your meetings.  Sending a direct note will better draw the team member’s attention.

The best project management organizations and companies out there understand that projects compete for resources, and they plan accordingly.  They have governance bodies that weigh the importance of one project versus another, and they have an elaborate ranking system for establishing the priorities of projects so that everyone can see clearly what project comes first when there are resource bottlenecks.  The PMO usually works very closely with these organizations to keep their projects running well.

What about operations?  How does this fit in?

The reality of most companies is that they do not have seperate project-based resources versus operations-based resources.  Major operational initiatives and problems can derail your project quickly.  An over-abundance of projects can rob Operations so thoroughly that needed maintenance is ignored, and your operations deteriorate (just ask the american government about this).  Major operational problems clash with major project initiatives.  Huge political battles can ensue, creating inaction as people who need to do do the work in question instead go sit in meetings waiting for a decision on which work to do.  People end up making decisions on an island at times, just picking a direction based on their own personal knowledge rather than wait on the corporate machine to find a direction.

Rather than get lost in these situations, get a grip on your Operations.  Include them in the resource planning process.  Most importantly, include them in your prioritization process.  Is the most important project in the company more important than maintenance of the most important existing product?  What about the fifth most important product?  The fifteenth?  Which customers’ business is more important than your projects?  Customer problems can just as easily steal resources.  Not all of your customers will be more important than the development of your company’s future either.  You have to count them as part of your prioritization process, and you have to make hard decisions like this.

Doing this type of process is hard.  It is also vital to your company’s ability to react quickly and decisively to the unexpected.  You, and more importantly, your team, need to understand and agree on what comes first.

Ever worked on a project where things just seemed to be more and more designed by committee?  Ever think there’s probably a better way?  Today’s feature will probably be all too familiar.

Here’s a great commentary on how things are done today and a little what if thrown in…

What if the stop sign were designed today?

Enjoy!

Many types of projects involve prolonged engagements- client implementations, the building of large software systems, legacy migrations, the list goes on and on.  Most of us have led or been involved in these types of projects.  Many of us have been involved in projects that failed, were cancelled, or just needed to be killed before they got out of hand.  So where was the exit strategy?

A risk to the company and stakeholders of every major project is how to exit out of the project in the event that it fails.  This risk seldom makes it into project plans, though, because all of the project manager’s tasks are typically related to identifying and reconciling risks that might cause the project to end- in other words, to preventing an exit strategy from ever being used.  So where does this fall?

I recommend that this should be worked into any PMO’s processes.  The inability to gracefully shut down one project when it needs to be shut down is a huge risk to your overall portfolio and to the company itself.  Most of the time, the plan may be very simple, but working with your sponsor and stakeholders to identify how to recognize when the project needs to be shut down and what the process is very sensible, holistic risk avoidance for all involved.

Here’s what was being talked about on UF this time last year:

PMing on the cheap: TaskBin free online project management

PMS Relief: Guerilla Tactics for Project Management

Is Consulting for You?

Four Things You Can Do to Hire Better and Head Off Resource Issues Early

This week’s PMS Relief is yet another guide to that favorite application that we love to hate:  Powerpoint.  Enjoy!

How not to use Powerpoint

We all start somewhere.  I remember when I began on my current career.  It was nearly thirty years ago now, sitting at the dinner table with my parents.  My father has been involved in manufacturing management of one sort or another for almost all of his career.  Talk around the dinner table turned to his work from time to time, and I was interested.  My father has never talked a lot nor had a ton of hobbies; this was something he was interested in, so I tried to be interested too.  He brought home odd books from time to time with wierd terms in them like “JIT” and “Kanban”, so I poked around in them and read, as I tended to do with all books I found with new things in them.  As I grew older, the conversation got more interesting; talk often revolved around how people behaved, why they did what they did, mistakes they made, ways things could be better.  As I became a teenager and started to have social problems at school and in my personal life, Dad’s stories and allegories to help often had a workplace bent to them.

In the summer after high school is when I truly became immersed.  I got a summer job before college at my father’s company.  I got first-hand experience with business and all the strange things that seemed to go wrong.  Through conversations with my father, my boss, and other folks, I started piecing together how management really worked.  By this time, Dad was starting to specialize- he was working in Tooling management.  If you don’t know what tooling is, that’s the specialists who build the special tools and fittings and whatnot that factories use to make things.  It’s that special part of manufacturing that fits in the same place that developers do for business.  Every fall and spring I went to college and learned… well, mostly about women, but nearly every summer I went to work in the factories where my father worked and gathered the education that put me where I am today.

I never really realized it until the past few years just how much what I learned from my father really mattered.  So much of what he said and did and taught me applies directly to what I do today.  Even the things he didn’t teach me directly, he still originated.  I still remember the first time I finally cracked open one of Tom Peters’ books.  I picked the book up at a yard sale after remembering having seen it in Dad’s books; I read it on a trip to Seattle, and it changed my worldview.

Today is my father’s birthday.  He’s getting closer and closer to retirement by the year.  Last year was the first year I finally caught up with him careerwise.  My father’s position in his company is on par with mine, but the title is different.  He could have climbed higher if he wanted; Dad stuck with the level he felt was right for him.  If it weren’t for him, I’m sure I would still be learning my way up the ladder at a pace that, with my famed impatience, would probably be hurting my career more than helping.

Over the last year in my new job I’ve had somewhat of a new mentor in my career.  It’s the second mentor in my life, and I am still feeling my way.  I still rely on my first mentor for advice here and there (especially when I need guidance on how to deal with my second mentor).  I find as I get older that I grow impatient and frustrated with Dad’s advice more often somehow, that in what I’ve learned on my own I have more trouble stepping back and looking at it from the right perspective to understand.  Perhaps I grow set in my ways as I grow old.  Still, when I finally can step back and see things without letting emotion get in the way, the advice always seems to fit and help and guide me.

I find myself now quoting my father more and more.  I also find myself starting to mentor others in their careers.  It’s amazing the people who become interested in management and leadership when you put the right guidance in front of them and offer up a bit of responsibility.

My main point here, besides honoring my father’s birthday, is that you should honor your mentors in life, give them credit, and when you are struggling with their advice, be patient, be patient, and think it through one more time.  Pass on the knowledge and, when the time is right, be a mentor to others.  Most but not least, don’t forget to thank them.

Thanks Pop.

How often has this happened to you:

You give a long report about what’s going on with the project, what the current status looks like, when you expect to deliver.  After you finish, you open the room up to questions.  No one has any.  At all.  After the meeting, you check with the sponsor- it’s an important sponsor - and he says he understands and is impatient for completion of the project.  After engaging him in conversation about the deliverables you are wrapping up, he asks some odd questions, you probe more… and realize he doesn’t understand what you’re about to deliver to him at all.  He’s working off assumptions.

This is (unfortunately) not an uncommon experience in the workplace.  The part of this situation I want to illustrate is how you learned what was truly going on:  by what the person asked.  Most people believe that they understand what’s going on- otherwise, they will voluntarily ask questions.  They don’t dodge asking questions out of any insistence on not knowing what’s going on.  You must seek what they don’t know- what they do ask questions about- if you want to know what they believe is going on.  Seeking inquiries and digging into details with someone will invariably lead you to their view on things.

It’s an old mantra, but it’s true:  Judge people not by what they say, but by what they ask.  Use this to your advantage.  Never be satisfied with just what they say.  Seek their questions.