Leave a comment

Leading, Managing, Doing

By:  Philip Smith

Phil Smith Bridge360I recently traveled to Europe on a business trip and was sitting up late in the hotel catching up on things that had happened at the home office while I was in flight.  I had the TV on in the background with a World War II documentary to keep me company. Fortunately the documentary ended and I was able to get back to the business at hand, but not before I picked up on a recurring point the documentary was making, which was Rommel’s impressive ability to lead his armies both strategically and tactically.  General Erwin Johannes Eugen Rommel (15 November 1891 – 14 October 1944), popularly known as The Desert Fox, continuously sought out ways to be unpredictable and grabbed geographic advantages even when it did not look possible. Fortunately for the Allied forces, Rommel usually over-achieved his goals, unintentionally overextending his ability to hold a region, or leaving a critical supply line vulnerable.

I actually committed to this blog title a while back, as I was planning to write about the difference between leading, managing, and doing.  I was going to differentiate leaders as people who motivate, encourage, strategize, manage risk, and build balance within the business domain (people, business, and customer). I was going to describe the doers as the people who have the skills, training, capability, and motivation to show up for work every day and get the job done, whatever that job might be.  These doers have respect for their profession and manage their career to the best of their ability. The managers in the middle bring it all together. They are the team builders, the front lines to the client, the make-sure-it-gets-done-no-matter-what people, and the example to the rest of the team. I was going to dig into these concepts and attempt to surface some original wisdom.

However, that documentary took me briefly away from my workplace and put me on a different thought plane about leadership. The wisdom here is that success can result from surprising the competition. Internally, a leader must be consistent and predictable, such that the established vision can actually be achieved. Externally, it is best to leave competitors wondering what you, the market leader might be reinventing.

Managers are the people who enable leaders to lead. Their ability to comprehend the challenges their teams face while also working in support the larger objectives requires them to be creative on a daily basis. The team members who work in support of the managers also bring creativity to their work. At Bridge360, our people invent and reinvent on a daily basis, regardless of role. Sure, we’re not lighting homes on fire to conceal our forces (that would be ridiculous in peace time), but we are finding better ways to implement complex business rules in a legacy payment system. We are helping a client use new technology to improve their collection of marketing information, which will help with market penetration. We are implementing a website with reusable design elements and code snippets to allow a client to accelerate a massive technology refresh. And in the business that we were founded on, testing, we are deploying key people with key skill sets to make sure that our client’s new projects are brought to market in a reliable fashion. These projects require clearly defined roles, as well as the flexibility to be nimble and shape-shift (or even fully integrate ourselves into our client’s team structure) based on what the project may require.

Leading, managing, and doing… we are accomplishing it in surprising ways at all levels in the organization, and more importantly we are doing it for and with our clients.


Leave a comment

The Tale of the Process Challenged Pig

by Phillip Smith, Vice President of Operations and Services

Phil Smith Bridge360Once upon a time there was a wolf and three pigs.  One pig acted in a cost conscious manner.  One acted with urgency.  The other one… well, he stayed in business long enough to tell the story.  In IT, we need all three attributes:  cost consciousness, motivation, and quality focus.  Yes, the quality conscious pig who built with reliable design and materials is going to be the first one that I’ll select to be on my project team.  This individual not only cared about the end result, but he (not being gender biased here; I looked it up and the three pigs were males, sorry ladies) cared about the process.  He thought about how to measure success (security was considered in the requirements) and about sustainability (I understand a wood stove and a chimney were included).  The windows had curtains and shutters which increased usability, and the foundation was solid with an open floor plan in case of further expansion.

The third pig used a process to get to his end result.  He did not react; he planned.  He followed what he had learned in the past and put his best skills and resources to work.

In real life, I don’t get to pre-wire all of the members of a project team, and most of them, myself included, are not wired like that last pig.  In fact, most of us are wired with action (get it done, move on to the next task) and with a tendency to think about getting there with low cost, which is always noble and usually rewarded.  In fact, most of us have to stop and remind ourselves of the things we were taught that may not be inherent in our genes—namely, to plan and deliberately execute, rather than to simply execute.

Therefore, project teams, by nature, are made up of people with a mixture of tendencies, and many of them will not be process oriented.  It is important that teams be intentionally staffed and supported by people who value process and are capable of influencing their other team members.

When we drive our cars, we all follow a basic set of rules based on lanes, signals, and safety.  We all understand and accept these rules, and follow along with them without much discussion.  Yes, similar rules exist in the world of software development.

Such as:

  • Requirements should be documented and validated
  • Testing should be planned
  • Work products should be reviewed
  • Team members should be trained

I could go on for a while with this list.  And, very few in the software industry would argue with these basic rules.  Yet some of the most talented engineers are comfortable moving straight from a conversation with the client to writing code.

I want these talented engineers on the team.  I also want to balance their action oriented initiative with some process so that the end result is similar to the brick house.  If the three pigs had pooled their talents, they would have all been better off.

One parting shot… don’t load your whole team with process people unless you are creating a PMO.  They are certainly invaluable, but if you put them all together they will build a better process, not a brick house.


1 Comment

Should “Good Technical People” Manage Projects?

by Phillip Smith, Vice President Operations and Services

Phil Smith Bridge360I’ve seen many people in the IT industry think about shifting from a “software engineering” job over to project management.  When I come across these folks in discussions, I stay on topic with the person long enough to discover their real motivation for change.  I ask them to think about how they want to spend their workday, because it really is important to maintain alignment between the way people are wired and the type of work they are asked to perform.

So let’s talk about the general differences between the two “types” of people we typically see in technical roles vs. project management roles.

People who excel with technical work are a strong blend of “idea” and “action” in terms of the way they are wired.  They love submersing themselves with great technical ideas and they are motivated to make use of all of the available tools and tricks.  They often use their free time keeping up with new technology, simply because they have a passion about it and have an appetite to keep learning.  They may stay up late at night reading manuals, or publications, or tinkering with things on their home network.  I don’t want to discount the teamwork aspects of working with technology, because they are critical to success.  However, working with technology does require a person to be comfortable with working many of their hours independently and somewhat isolated, because they are typically assigned tasks that require research and original thought that is performed at the individual level.

In contrast, project management work is very “people” and “process” centric.  Most of a project managers’ time is spent building relationship and influencing people.  They spend time facilitating meetings, gathering information, and communicating status or resolving issues.  A project manager who is savvy enough to manage their schedule, cost, and risk through constant communication will be even more successful if they also love taking advantage of formal processes.  When I refer to formal process, I’m referring to defined work patterns, tools, templates, and mechanisms for reporting and tracking.  A project manager will go to sleep very quickly if you put him or her in front of a technical manual, but that same person will become energized if you strike up a conversation about earned value or resource leveling.

Again, my point comes back to the question of how a person likes to spend their day.  If they are passionate about technology they are likely to be miserable if their job requires them to navigate organizational politics and never gives them time to work through the riddles of writing efficient code.  To this I say, let them be architects and engineers—why ask them to be project managers?

I will concede that there are a few people around who are oriented strongly as a mix of people, process, idea, and action.  These people are sometimes confused by the distinctions I’ve presented here because they are just as happy to be accomplishing something on their own in isolation as they are accomplishing things in a group setting where a lot of people interaction is required.  These folks can leap from a PM role to a technology role quite comfortably.  You’ll often find them excelling in various parts of the software development cycle as product managers, business analysts, technical leaders, or as quality assurance specialists.  These roles require a mix of technical understanding and desire to work with people and process.  So next time one of your technical people talks to you about doing project management work, ask them:  “How do you like to spend your day?”


1 Comment

Why You Should Think of People as Raw Materials

by Phillip Smith

Those of us in the service industry do not always have something tangible to show as a result of our work. Compare us to people who build things (like roads, or boats, or furniture) or to people who refine, grow, weave, or clean (to provide fuels, clothing, or foods) and we’re quickly at a loss to point to anything physical that is the result of our efforts. Extend the comparison a bit further to folks who perform, write, invent, or design, and we still fall short in terms of having a tangible product. However, that does not mean that we, specifically those of us who sell or provide a service, are not building something.

Consider the absolute best outcome of a good day’s work in the service industry: the result is a new or improved “relationship.” Yes, people who work in sales and service are building; they are building relationships.

To the casual observer, it may appear that they are explaining the features of a product, or in the case of something closer to my daily work, deploying high quality software into your business environment. And that is the day-to-day picture of what we do. However, the observer who is looking a bit deeper sees us doing more than filling a role in order to put food on the table. We are building expectations, trust, and ethical standards that result in long lasting high value relationships. In these cases “tangible” falls short of being a good measurement of value because the end result is anything but an end. Solid relationships, new processes, better standards—these have a ripple effect in the way people do business, and even if the work didn’t result in the next greatest invention, it’s still the kind of stuff that changes the world.

I’ve not presented anything revolutionary in this article. I’m hoping however, that I caught your eye with the title and that you’ll be willing to think about your hiring, training, and culture in a slightly different way. You would not assemble furniture using an unreliable design or with poor quality components. You should think of the people in your service company the same way that you think of the materials that you might use to make a salable product, with the exception that you are using these people to build relationships that make your business successful.

Are they the best people you can find? Have you trained them well and set them up for success? Are they true critical thinkers, not satisfied until they’ve found the best way of doing something? Have you set the right example with the relationships that you maintain with your clients and with your employees?

Have you communicated the right message to your employees, so they understand how to win repeat business? A smile and a willingness to view the service from the client’s point of view is a key ingredient to repeat business, and it’s not always something you can teach. The people that do your smiling are doing what they love, caring about the results and invested in the outcome—and they are the equivalent of the grapes that go into a fine wine.


4 Comments

Ailing Projects: Should PM’s Treat the Symptoms, or the Root Cause?

by Phillip Smith

In my previous article I wrote about IT projects experiencing trouble, and separated the symptoms from the root causes. Doctors sometimes treat symptoms, and sometime they treat root causes.  Other times they treat both or do nothing at all. In this case, the project is the ailing patient, and the specific medicines that a project manager chooses to administer—and when—is largely a matter of style.

Some project managers are comfortable allowing a certain amount of churn to take place before they step in, while others work in a more hands-on mode. If the project team is seasoned and is using a mature development process, the PM can afford to allow that team space and time to work through problems without having to personally drive a resolution for each problem.  There is a balance between empowering the team and being so distant that you appear to be “checked out”.  Find that balance (it will vary by project and by team) and use it to your advantage.  Teams that work independently within a process set tend to accomplish a lot –  and they tend to have great morale when they are productive and know they have a PM who will drive resolution for issues when they need that kind of help.

While I’m willing to admit that the PM has a right to bring a certain amount of style to their approach, I’m also willing to make a strong argument that various situations call for certain “medicines”.  In the last article I listed classic symptoms of a project being in trouble. One of these was “high defect rate.”  We can use that as an example of a situation that calls for specific action. Continue reading


2 Comments

Project Management or Project Meteorology? Forecasting, Monitoring and Prevention Measures to Stop “Bad Weather” Before it Happens

by Phillip Smith

Project planning is an exercise in forecasting.  The idea is to take the variables you can account for and try to anticipate any issues that might rain on (or dry up) your project’s progress toward a smooth conclusion. Forecasts are rarely perfect, which is why we have project managers still assigned to projects even after the plans are built.  We need the PM’s there to lead teams through time and change and keep the project in scope.

That’s why the real mark of a good PM is discernment on the fly. PM’s, while leading their teams, must be able to distinguish the difference between normal variation from plan and real trouble–and be able to recognize the difference between the two in time to mitigate and control.  Sometimes re-planning is required, but the goal in most instances should be to return to the original plan whenever possible.

So how do you know the difference between normal variation and real trouble in a project? A textbook answer would involve the use of metrics plans.  If defects (severity, volume), schedule variation, budget, or productivity reach beyond established thresholds, then corrective action must be taken. The metrics required to monitor the project are expensive, and we don’t all have them available to us. So many PM’s are working without formal metrics, and must diagnose real trouble before it is too late.  Fortunately, there are some general rules of thumb. Ailing projects have some common symptoms, many of which formal metrics account for and an observant PM can easily identify. Here’s what to watch for:

Classic Symptoms of an Ailing Project
Scope unstable
Missed deadlines
High defect rate
Unexpected costs, or lack of expected costs
Low team morale or other HR issues
Nervous client
Budget problems

Continue reading