Category Archives: Project management

How to scale your PMO in 99 simple steps

Posted on by
Reply

Okay don’t take the title literally. There are much fewer than 99 steps, though it is not simple.

I’ve worked for several small IT managed service providers. Like every company that survives its first few years, there comes a point in time when the organization must mature in order to scale and grow. I’ve taken part in a couple of such efforts, and I can’t help but feel we always nibbled around the edges on the PMO side. Most people with a pulse tend to intuitively know what the areas of improvement are. This is evidenced by all the complaining we hear at work about dysfunctional processes, teams, etc. But there are different approaches to actually driving and managing change.

I recently went through a thought exercise, mostly on the elliptical and in the shower, of how I might approach improving an immature PMO holistically and strategically. Below is a lightly edited braindump of this exercise. I specifically had an IT managed service provider in mind. But much of it is broadly applicable with minor tweaks.

Hopefully someone out there finds this useful as a starting point or for idea generation.

PMO Improvement Program

  • Establish RACI for each initiative, 1 person accountable.  Part of performance review.
  • Establish governance for program.

Pillar I – Organizational Alignment

Pillar II – Standards, Process & Procedure

Pillar III – Performance Measurement

Pillar IV – Staff Development

Falling on one’s sword for others

Posted on by
Reply

In this first installment of the Dark Side of Project Management, I’ll tackle a thorny practice that can really breed resentment.  My research, and by that I mean five minutes of Googling, indicates that the expression “falling on one’s sword” dates back to the Roman Empire.  Military leaders would literally fall on their sword and commit suicide after an embarrassing defeat.  This was a way of taking responsibility and owning up to their failure.  The phrase is sometimes used in business today and it basically means to apologize, resign over or otherwise take responsibility for an error with a gesture.  The phrase is usually reserved for big screw-ups in my experience.

There’s nothing wrong with owning up to one’s mistakes.  In fact, a PM should always own up to their mistakes.  But this post isn’t about that.  It’s about owning up to others’ mistakes or failures, or put another way accepting blame for others.  This phenomena is in no way unique to PMs.  There are many motivations employees may have for covering for their coworkers.  In the PM world, you’ll see this practice more often when engaging in client-facing projects.  Why?  A PM may be tempted to protect other team members as well as the image of their company.

Project managers, have you experienced any of these situations on a client-facing project?

  • A critical project team member is suddenly pulled off time-sensitive work for a support or operational issue and as a result is unable to complete project work by the agreed upon deadline.
  • An experienced project team member makes a very rookie mistake, adversely affecting the project.  And by the way, this usually will happen when the team member is forced to do too much multitasking and is unable to focus.
  • The client asks for some basic common piece of product or operational documentation and it doesn’t exist.
  • A senior leader in your organization has a side conversation with the client and promises something unrealistic related to your project.

If you have experienced any of these or other similar situations, you may have been tempted or felt you had to take one for the team.  What’s worse, a PM does not need to explicitly accept blame to be judged harshly by the client.  Whenever a project does not live up to expectations, in the absence of another explanation, the client will always naturally blame the PM.

If you find yourself looking bad repeatedly due to other team members or organizational shortcomings, it can be career limiting – especially if you intend to stay in the particular industry you are in.  You do not want your reputation to take a hit due to factors beyond your control.  Plus your job satisfaction can’t be very high if you find this happening to you.  So what should you do?

What you should not do is make up fictitious excuses.  This is flat out unethical.  Though I will say I’ve seen some very skillful wordsmiths come up with explanations that downplay a deficiency while not out and out lying.  For example one can make a resource crisis that would look embarrassing sound more like a temporary hiccup: “Unfortunately Joe resigned today (truth).  We’ll just need a couple weeks for another engineer to free up.” when you actually need to hire someone to replace Joe because he’s your only X.  Telling these half truths is also not a good game plan.  It may save your bacon here and there, but if you keep doing it you eventually start to smell like a rat.  And as I indicated earlier, at the end of the day the client will blame you anyway when the project doesn’t go well.  Finding oneself telling a lot of half truths and doing frequent damage control with clients is often the first sign of an endemic problem.

What you should do first is engage your influencing skills and tackle the problem head on.  If you cannot effectively influence the person or people who can rectify the problem, talk with your manager.  Make sure you have concrete facts that demonstrate how your reputation is unjustly taking a hit.  If your manager does not or cannot help, it may be time to update your resume.  I don’t care how much you may be earning, it’s not worth the career hit.  Don’t be shortsighted.  And don’t convince yourself that it’ll eventually get better unless there’s reason to.  That’s being a victim.

In short, don’t make a habit of falling on your sword for others.  You deserve better.  In closing, I want to leave you with something to chew on.  You know all those incompetent vendor PMs you’ve come across over the years?  Could it be that some of them were not in fact incompetent, but rather falling on their sword for others?  Maybe we should try to give them the benefit of the doubt, or at least a little more rope.

Good luck out there PMs!

The dark side of project management

Posted on by
Reply

There are myriad useful project management resources and articles on the web.  A PM can learn about agile methodologies, download templates for common project artifacts and read countless articles on best practices and real-world case studies.  So naturally, for my part, I’ve decided to go in a… well… a different direction.  I’ve decided to publish a series of (occasional) blog posts on another side of project management – the dark side (MUAHAHA!!).

I’ve been working on IT projects for about 15 years in various roles: technical SME, project engineer, project manager, program manager, service provider PM and others.  I’ve often served multiple roles on a single project.  And I’ve worked for a number of scrappy small and medium sized organizations that have at times been in tough situations.  This is relevant because one tends to find some of the following conditions at smaller companies:

  1. Overreaching / overcommitting in an attempt to grow a book of business.
  2. Less formalization of policy, process and procedure than larger organizations.
  3. Agility – changing strategy and priorities quickly and frequently.
  4. Inexperienced leaders (including yours truly) and staffing gaps.
  5. “Fake it ‘til you make it” survivalist culture.

And it is conditions like these that can make a project go sideways, upside down or inside out.  In this series I will draw on first-hand experience and my observations of others’ tough experiences.  I will also offer my opinions and advice along the way.  I will not be recounting actual events, merely using my professional experience to inform my coverage of some tough topics you didn’t learn about in your PMP classes.

I’ll be posting my first installment next week:  Falling on your sword for others.

Thoughts on agile IT infrastructure

Posted on by
Reply

Since losing my job in March I’ve been using some of my time for professional development. One of my pursuits is learning about agile project management with a focus on Scrum. As someone who has spent most of his career in IT infrastructure and operations, I have had limited exposure to agile. Agile is primarily geared towards software development projects, though it can be used for just about anything. I’ve been seeing and hearing the term more and more often, including in just about every project management job ad.

My recent research has consisted of:

  • The ITProTV Agile Scrum Master course
  • Two seminal books by Mike Cohn, one of the founders of the Scrum Alliance
    o Succeeding with Agile
    o Agile Estimating and Planning
  • Several blog posts and articles on the web related to agile IT infrastructure practices

At this point I’m sold on the advantages of agile. Cohn does a great job of backing up the advantages with studies. For my part I am interested in exploring how best to utilize agile practices in IT infrastructure projects and potentially operations. Following are some observations on the subject based on my research:

Agile is incompatible with fixed fee contracts
Okay this heading is a bit bold (har har), but there’s definitely a lot of truth to it. I worked for an IT managed service provider the past couple years. Most of our client engagements were in IT infrastructure hosting and management. And most of our implementation contracts with our clients were fixed fee. Fixed fee is common in projects with a well defined, well understood product or service being delivered.

One of the tenets of agile is to welcome change – to scope, budget, schedule. If the client realizes that an additional feature would be very useful or that they no longer need a certain aspect of the product, we should oblige them. Scrum in particular eschews detailed contracts that attempt to lock down scope. This is at odds with fixed fee contracts. With a fixed fee contract, the project manager is incentivized to prevent scope creep so as not to add work that will drive the project over budget and late. There is typically a formal scope change process which makes the impact clear to the client.

So I would conclude that agile projects should be T&M or similar. It’s fine to provide some estimate up front, but the client must go into the engagement with eyes open to the fact this is an agile project and they should have an understanding of what that means. It ultimately benefits them, but there are expectations of them as well. I recently interviewed with a company in the software development and customization world and I asked about this in the interview. They indeed bill T&M and agreed that their projects and agile practices would not work with fixed fee.

Thou shalt form squads
I am not a big fan of marketing terms or catchy terms people come up with for things. I’m still getting used to user stories and daily scrums. But in my agile research I did find one that I like – SQUADS! As best I can tell this is not a scrum term, but I have been hearing it in agile contexts. I take it to be synonymous with agile teams. A squad is a multidisciplinary team. In the software development world the team may consist of developers, database designers, UX designers, architects, testers, etc. In the infrastructure world a squad may include systems engineers, network engineers, DBAs, ops folks, etc. The idea here is to eliminate delay inducing hand-offs between functional teams and to build shared accountability and camaraderie. I actually applied for a job the other day with a title of Squad Manager. Pretty badass, huh? This comprehensive McKinsey article discusses how squads work in an infrastructure organization. In my experience smaller IT departments of say 20 or fewer are already in effect a squad. They tend to be collocated and in frequent contact. Though sometimes inserting different functional managers into a group of even this size can create barriers. The article suggests that in larger organizations infrastructure squads should be formed around applications or services. So maybe there’s a storage squad or a squad for a particular SaaS application. These squads can work in an operations mode or executing projects in their line of business.

Automate early
Automation has been a hot button topic in IT infrastructure for many years. From shell scripting to automation software packages to the cloud. Larger organizations have usually led the way due to the imperative to scale and the lack of scalability of manual processes. In agile software development, automated tests are critical. There is no test phase at the end of the project. Unit testing happens during each iteration as code is written. Integration testing may be run on a nightly basis against the code checked in end of day.

In the infrastructure world, automated testing or verification is nice to have – like comparing a farm of web servers against a configuration baseline perhaps. What’s even more critical in an agile world is automated operations. Like the use of squads, automation enables an infrastructure organization to become more responsive. Can we spin up a server or push out a configuration change to all our routers with the click of a button? Can we facilitate DevOps by providing self-service options to our developers?

In the project world, I think the usefulness of automation comes in either when working on large projects where a piece of infrastructure will need to be deployed many many times or in the case where you’re executing basically the same project over and over as does a service provider selling Office 365 for instance.

Projects vs. Operations
I think that agile practices can work both in the project world as well as daily operations. Certainly the particular practices I’ve covered in this article can be effective in both. One question I have is how this is all going to work cohesively in an IT organization? I don’t think adopting every agile practice is practical. IT folks need to use some common sense and adopt what makes sense in their particular environment.

For example, Cohn greatly prefers sticking to index cards for managing user stories, sprint tasks, parking lot charts, etc. But try to imagine a service desk that uses index cards for their service tickets. I think someone could make a pretty funny YouTube video on that premise, if they haven’t already. So do you use two systems, an analog one for project management and digital for service desk? Or do you try to find one that does it all? From the perspective of someone who has done reporting of service desk and projects side-by-side, I’d rather have everything in the same database. But maybe it’s better to just find the best system for each job. And while you can maybe put services into operation or perform continuous improvement in iterations, can you operate a service desk in iterations? Probably not. But you can certainly have a daily stand-up to prioritize tickets, review urgent tickets unresolved the prior day and make a game plan.

Your whole IT organization must be agile
If you have agile development teams in your organization, you must have agile infrastructure teams. At the very least you must have heavily automated processes for deploying infrastructure and you must be able to respond to requests from developers quickly. And you should probably have infrastructure representatives sitting in on development daily scrums or at least sprint planning meetings. This way you know what is coming your way and you even have some input.

The consequences of isolating agile to development are well covered by Cohn in “Succeeding with Agile”. At best, inability to complete user stories in some iterations. At worst, a backslide into old ways of developing software. In his book, Cohn provides strategies for getting HR, Facilities and the PMO on board as these are key groups needed to support agile development.

When not to be agile
Okay this is an intentionally incendiary heading. Of course we should always be as agile as possible given the constraints we are under. But in thinking about many of the infrastructure projects I’ve worked on, I would say that a lot of them were sequential by nature….. with many interlinking dependencies. And forget about having a “potentially releasable product” every two to four weeks. That just doesn’t make sense. For this type of a project, does it does it make sense to utilize an agile methodology? I don’t think there’s a hard and fast answer. I think one should employ as many agile practices as possible given the situation. If you are performing a virtual server migration where you are migrating servers in groups over the course of several months, there is an inherent iterative nature to the work and greater opportunity to be agile. In a more sequential project, one can still borrow practices like a daily stand-up meeting and keeping the team small and collocated if possible. One can display big visible charts and dedicate some time to building automated verification tests (if this type of work will be repeated).

One of the big reasons agile software development de-emphasizes up-front planning and estimates work with a unit-less measure (story points) is the acknowledgement that we cannot know the end product with any real clarity before we start building it. It is a waste of time and effort to do a detailed requirements analysis phase. And schedule estimates made before execution begins will inevitably be wildly inaccurate.

With infrastructure projects these things are typically less true. Sometimes we know the end state with a great deal of clarity. Although I can also think of countless instances where the project team and the customer had mismatched expectations. In that vein I try to use historical data to estimate whenever possible. I also employ what the Project Management Institute calls rolling wave planning, which basically means to plan out the first execution phase in detail and later phases in less detail – maybe a milestone plan only. Then break out details of the later phases just before execution starts. This doesn’t help at all with estimating schedule, but it does move planning to more appropriate times when we have as much information as possible to make decisions.

My point is that an infrastructure PM on a sequential project can utilize a waterfall methodology AND adopt certain agile practices as appropriate. I don’t know how an agile purist would feel about this, but I can certainly envision situations where this would be the best approach in my mind. I am very interested to learn how IT infrastructure and operations folks are utilizing agile practices, what successes they’ve had, what pitfalls they’ve run into and some of the adaptations they’ve come up with to suit their situations.