Enterprise Software

A conversation with a knowledge management guru, part two

It takes teamwork to deliver results on a major technology project. Skip McDonald, director of knowledge management for Luminant, fosters teamwork among his firm's consultants to get the job done well.

They say it takes a whole village to raise a child, and the same concept is often true for large technology projects: It takes a team of experts to bring it to fruition.

So explains Wylie W. "Skip" McDonald, director of knowledge management for Luminant Worldwide Corporation. The consultants at Luminant work in teams; McDonald’s duty is to ensure that each member is working toward the same vision for the end result.

As a veteran IT consultant and technical project manager, McDonald is an acknowledged authority on technical architecture, knowledge management, and the effective application of people, processes, and technology to meet business opportunities.

In part one of columnist Rick Freedman’s interview with McDonald, they discussed what it takes to motivate consultants. In the second half, which appears here, they explore the full-service agency model, fostering teamwork, and the qualities of a good IT consultant.

Accomplishing goals through teamwork
TR: Luminant is a full-service agency model, focusing on the full range of services, not just technology but strategy, branding, marketing, and so on. How do you define “consultant” in that environment?
McDonald: All of our people are consultants, whether they’re creative consultants, technical architecture consultants, marketing consultants, or strategic consultants. They don’t necessarily have that title on each project, because we use a role structure—what is the role this individual is playing. We find that using a role-based structure simplifies things immediately. Even though a consultant can do lots of things, if she’s a DBA on this project, that’s her role. Within the methodology we focus on defining the roles for each engagement. A consultant can have one, two, or lots of roles on a project, but as long as the role is defined and we have coverage, we’re okay. This structure gives our folks the chance to go both broad and deep.

The typical IT consultant would be deep in a technical discipline, and we have folks like that who we put on a career track as specialists. We have other folks who are not technical, like usability architects. We also have consultants who are extremely deep in business strategy or business process, who are fairly shallow in the technical delivery piece. Our project managers are deep in their disciplines, and they leverage the technical specialists to fill in where they don’t have the expertise. We’re totally team-oriented here. We build teams that cover all the disciplines. At some points in the projects our Oracle guru, for example, is leading, and at other points they’re following, depending on how the roles are laid out. One of the things that differentiates us is that we don’t have a problem with that kind of ambiguity. For someone who just wants to be deep in Oracle, for instance, they may not be the right fit for our type of organization.

TR: So, if I’m a Luminant consultant with terrific depth in Oracle, and my counselor has recognized that I have the potential to become more of a strategic advisor, how does Luminant help me elevate my skill set?
McDonald: That’s a perfect case. First, we’ll have a conversation with you to see if that’s where you want to go. There has to be willingness. Then the counselor will develop some actionable things to help you grow, like to say, “Let’s get you staffed on a project where you play a significant role in the business analysis.”

TR: So it’s a peer learning process.
McDonald: Absolutely. And our project base is such that we can do that. That person would be a follower during the business analysis part, and then when the data-modeling piece came up, he might be a leader and the other team members would be followers. We’re focused on building strength on strength. We’ll roll people on and off of projects as their development needs and the needs of the project dictate. We’ll also work with people that we want to become thought leaders, to write or speak at conferences and such. We say, “if you want an opportunity to be special, let’s take it to the next mile.” We have folks who we’ve helped prepare so they can go back and forth between different roles, and it’s been a tremendous building opportunity for them. We have folks who came in with great technical skills, and we’ve developed them so they now have great strategic skills, great e-business skills, and now are able to contribute to the full project lifecycle from the proposal stage, selling and closing the work, all the way through maintaining and sustaining the system.

Creating a shared vision
TR: Do clients understand the concept of fluid project teams? A lot of clients really value the stability of the teams and appreciate the chance to develop relationships with consultants who then stay through the project lifecycle. Do your clients struggle with changing team membership?
McDonald: Most clients don’t seem to mind it. A lot of clients have actually pushed us to take our consultants offsite to our own facilities to do the work. But, for those projects where the consultants are delivering services onsite, there is a need to have stability. Typically it’s the project manager, the core team, and then the relationships are built peer-to-peer. When it’s a mixed team and we’re working hand-in-hand with the client, then stability is extremely important.

TR: How do you ensure that the vision that your consulting team is working toward is the same vision that the client has for the end product?
McDonald: We start early in the process. We help the client to understand what questions they need to ask: Should I be in this business, what will fundamentally change when I go from my brick-and-mortar business to an Internet business? We’re helping them understand at the strategic level what are the questions we need to ask, what have other clients experienced that I need to think about. We set expectations up front with our clients regarding what their customers will expect to experience when they go to our client’s Web site. Why are we even going to the Web? We bring up lots of questions for their senior management to answer and mull over, and then we work together to answer those questions. This process typically uncovers a portfolio of business opportunities for the client, some of which we handle, some of which we advise clients to handle themselves, and some of which we decide together aren’t worth pursuing. The opportunities we decide to pursue feed down into the program we develop with the client, and then the details feed down into the scope. We then make determinations about the disciplines we need to bring to bear, such as marketing, branding, creative, information architecture, or our other disciplines. We apply all of those disciplines to achieve the overall program goals.

So our methodology helps us break out the overall objectives: What do we need to support those? Do we need projects, programs, investments? Does the client have to create a new division? Do they have to create a new business to support this, or will it be integrated into what they’re already doing? We then build an integrated interdisciplinary project team, so we avoid having a separate scope of work for marketing, and one for branding, and one for technical architecture. We want to avoid the communication overhead between teams. When you’re trying to move fast and get projects implemented quickly, that formal communication and interim documentation can get in the way.

Strategies for implementing at Internet speed
TR: So having it all on the same scope of work and the same project plan is one of Luminant’s strategies for implementing at Internet speed?
McDonald: You still have all the inter-team communications, but they’re happening verbally across a desk and they’re having a dialog about it, which takes a lot less time than documents and e-mails flying back and forth. Sometimes we do have teams that are working coast to coast on a project, and so there are times when we do need to get more formal with our communications and methodologies. So when we start, we have a kickoff with the team that we choose, and we develop a road map. For instance, we have a set of releases scheduled, and we say, “For release one, here’s the goal, and for release two, here’s the new set of goals. In release three, we fix whatever we learned in release one and two.” So our methodology also instills the idea that it’s not a project and then you’re done, you walk out and leave. It’s a series of releases that you develop over time to meet that overall business goal, because that business goal hasn’t been met by the very first release of the very first Web site.

TR: So to implement quickly, you use versioning, hitting the top goals and gaining some operational experience together with release one, and then let’s incrementally build to the ultimate goal.
McDonald: That’s intentional. If you look at a typical waterfall methodology project, you’ve got a box that contains the requirements definition, a box that contains the detailed scope, another box that contains the implementation, and then the consultants come in and build the thing, the client turns the handle, and you’re done.

TR: The consultants go home and on their way out the door they say, “Good luck!”
McDonald: We look at the whole scope, the overall goal, and if we were to just build this whole thing, here’s the benefit you’re going to get. But we all know that goal is going to move. So we take the piece that gives the most important benefit, the biggest hit from the business standpoint, and also the highest risk, and we tackle those. Let’s take the risk out of the project. Let’s implement three quick releases. The first release is to get a base functionality out. The second release is going parallel with the first—it’s the base functionality with the addition of some things that we knew would take a bit longer technically to implement. Before the third release, we do some learning based on what we’ve done so far, because we can now measure the market. One thing that’s great about the Internet—you know you’re successful or not almost immediately. Then you can add the details that will make it more effective. And you’re not two years into it, you’re months into it, and you’ve got 80 percent of the functionality and you’ve only spent 50 percent of the budget. Now you can measure what you’ve done and make decisions about how to effectively spend the other 50 percent of the money. The scope will change based on what you’ve learned, so you spend some time revisiting the strategy.

So we’ve done two things. We’ve delivered increasing functionality over the life of the project, while spending half the money you would have spent on a waterfall project. We’ve got 80 percent of the functionality, and we can now respond as the market moves. We can tell the client that this is not the end of the game. Let’s talk about where the market is now. Maybe you’ll need to spend some more money to stay in the game, but the client is in the game, perhaps making money, certainly learning what they need to do to be successful in their Internet marketplace.

The makings of a great consultant
TR: So what qualities do you look for in a candidate as a Luminant consultant?
McDonald: The ideal candidate would be the person with a technical or creative specialty who has also done a few years worth of consulting, and finds that they are internally motivated. People that make things happen, not that have things happen to them. If a candidate feels like their motivation comes from outside and they have to be driven to achieve things, then that’s not the right person, but folks won’t typically learn that in school—they’ll learn that by being out in the business world. After we’ve hired someone like that, the assignments she gets will probably start out being narrowly focused and very technical. They’ll typically roll on during the detailed design phase of the project. They’ll stay on for the length of the project, so we’re not rolling them in to see just their technical part—they’ll get to see the whole movie.

TR: You’re not kicking them out at the intermission.
McDonald: They’ll get to write requirements, deal with technical issues, and design the database under a senior person’s direction. Everyone starts as a consultant—we don’t start people out as just a technical specialist. If they need help to be the kind of person that can contribute to a complete project, we’ll send them to a class on writing skills or presentation skills. We’ll let them get that full lifecycle experience four or five times, maybe with one client, so they that get a good understanding of that client’s business. So they’re learning the client’s business, they’re learning the soft skills like writing and presentation, they’re expanding their technical skills with Java or Oracle or whatever. At first, they may contribute a few slides, or a few paragraphs to an interdisciplinary document, and their contributions may be edited by someone the first few times. Since we’re growing so rapidly, consultants aren’t held back by grade or seniority. If a person is showing all the communication skills and the project skills, and they’re becoming popular with clients because they’re personable, those things are recognized and encouraged, and that person will get the opportunity to move up and be stretched in their next assignment. We’re always looking to help people stretch.

TR: So do you do project reviews at the end of engagements, like postmortems?
McDonald: Sometimes they are postmortems, because we examine our failures as well as our successes. We want to be set up so people can fail gracefully, because we recognize that if you’re not trying to innovate, you can always be successful. If you’re trying to innovate, you’re going to fail sometimes, you’re going to miss the mark. We want to fail gracefully and fail faster. Thomas Edison failed a thousand times trying to invent the light bulb, so the shortest distance to the light bulb was a thousand failures.

TR: It’s a meaningful cultural issue, because in environments that don’t encourage risk taking, you can lose significant time as people try to cover their backs and don’t step forward and say, “I tried this, it didn’t work, what do we need to do now?”
McDonald: Absolutely. The only way you can get in real trouble at Luminant is to not throw your hand up and ask for help. Forgetting to ask for help is the one unforgivable sin.

TR: So let me take you outside of the Luminant culture for a moment. For the independent consultant, how do you recommend that they develop their skills when they don’t have a big-company career development infrastructure?
That’s the biggest challenge I had when I ran my own little consulting business. They need to be confident enough in themselves and in their ability to learn and stretch, to take assignments, and to talk clients into awarding them assignments that are beyond their current capabilities but within their capability to learn and deliver. That’s the only way to stretch yourself. Not by pretending to be something that you’re not—that’s a good way to lose your credibility. But by being frank, to help customers realize that you’re stretching, and that you do it well, and then you can use them as a reference to say to the next customer, “It was successful, I stretched well, and I delivered."

Rick Freedman is the author of The IT Consultant: A Commonsense Framework for Managing the Client Relationship and the upcoming The Internet Consultant, both by Jossey Bass Publishers. He is the founder of Consulting Strategies Inc., a training firm that advises and mentors IT professional services firms in fundamental IT project management and consulting skills.

As a supplement to his Consultant Master Class column, Freedman periodically interviews a leading executive, practice manager, or consultant from the top IT professional service firms. According to Freedman, the practicing consultants out there every day, selling, planning, and delivering projects for clients are the real masters. By giving them a chance to share their concepts, techniques, and lessons learned, he hopes to build consensus among consultants on the industry’s best practices and methodologies. If you have a question for Rick, e-mail us.

About Rick Freedman

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

Editor's Picks

Free Newsletters, In your Inbox