Feeds:
Posts
Comments

Archive for the ‘Consulting 101’ Category

To follow-up on an earlier post, I decided to do a write-up that describes the different consultant roles on a project, in detail.

(Please note that the below information is specific to the niche software consulting I have been exposed to in my career, and may not apply to every type of consulting project.)

First of all, allow me to take a quick detour…

WYSIWYG (“what you see is what you get”)

So…this principle does not always apply when it comes to the fine art of selling and placing consultants on a project. Let me debunk some common myths when it comes to staffing:

  • Staffing is product of both time and individual skill sets – not just skill sets. For instance, if there is a consultant who is not the optimal candidate for a project, but the timing of the project is just right…let’s just say that timing is the overriding factor in this case. This is why consulting firms do their best to hire excellent overall consultants – so everyone can fit almost every need at any time. From what I’ve seen, consulting firms will do their absolute best to staff the right person for each project. However, other factors come into play that complicate matters (besides timing): size of the deal, key player politics, potential future sales, etc.
  • The experience and client list written on a consultant bio/resume that is sent in advance to the client for approval may be slightly embellished. I have never witnessed flat out lying (unless the consultant does it themselves – they write the bulk of their bio/resume), but I have seen plenty of embellishing. Remember: the goal of the consulting firm is to get the client to approve the consultant so the project can start and money can flow. Enough said. If you are a client and worried about staffing, set-up phone interviews with the proposed consultant team. Then you can ask the hard questions about background, experience, etc. In my opinion, clients don’t do this enough.
  • In addition, the title on the consultant’s bio/resume may not represent the role the consultant actually plays on the project. This may be embellished to make the client feel like the fit is good. For instance, someone who is considered to be a Sr. Consultant at the firm may be listed as an Architect or a Manager on their bio. They may not have the expected amount of experience in that area. But keep in mind that a consultant firm’s reputation is everything. So more likely than not, they are not going to staff someone who they feel can handle the big task being asked of them. Consulting firms don’t like to fail.
  • The consultant who initially sells you the project/software may not actually be on your project. There are special consultants who only do what we call “pre-sales” (someone who gets the client interested in the firm and/or software product). They have skills in other areas that are helpful – they are great sales people and can demo products well. They may not be the best consultants. In optimal situations, the consultant who does the initial interview is staffed on the project, thereby allowing for continuity and familiarity.

PROJECT ROLES

Sales

The sales person assigned to a client may be called a “Business Development Manager” (a.k.a. “BDM”), “Account Executive”, etc. They are the person you will hear from the most during the initial sales cycle. They may wine and dine you, get chummy with you, and act like they’re your best friend. Once the project starts, some will disappear – never to be heard from again unless there are: new contracts, change orders, issues with cost, issues with people, project parties, unpaid invoices, etc. If you’re lucky, you’ll get one who will be in constant communication with you throughout a project, developing a trusted relationship that you will come to appreciate over time. If you’re lucky

What to look for: I will be honest – I don’ t have personal experience in this area. The closest I’ve come is being involved on the pre-sales side.

I imagine you may want to look for the following traits:

  • Honest communication
  • A likeable and trustworthy nature
  • Continued presence throughout a project lifecycle and a genuine feeling of concern
  • Advocacy for you when it comes to the consulting firm and the product vendor

Management

Management usually encompasses any or all of the following titles: “Vice President”, “Partner”, “Engagement Manager”, “Project Manager”, “Project Lead”, “Principal”, and/or “Architect”. (Note: due to their specialized skill set, I have segregated Architects to the next section.)

The management team on a project includes the people the client management team interacts with the most. This usually includes a Project Manager and an Architect. The Vice President of Consulting may also make occassional visits. If there is an issue with the project it is up to this team to communicate it. They should be your first line of defense and your true consulting friend. You should have the utmost confidence in this team, and they should be your trusted advisor during the good, bad, and ugly. (Notice the overuse of the word “should” in the previous statements.)

Required role on a project? For whatever reason, there is a lot of controversy on this topic. Clients always want to shave costs, and this seems to be one of the first areas that get cut, especially the Project Manager role (probably because this is the most expensive area). I personally think that a project manager should exist for every single project, whether that role be fulfilled by the client or a consulting firm…no matter how small the project is. Sometimes this position is filled by a hybrid role – perhaps an Architect who is also the part-time Project Manager. I think there are many cases where this has worked well. In some situations, I think there may be a need to have several project managers – especially if there are multiple projects running concurrently.

Look at it this way – if no one is steering the boat, how will anyone know where it is going? And if  there are multiple boats – how will you keep them all in line?

What to look for: Management can take a variety of forms and roles. Therefore, it’s hard to nail down a specific set of characteristics.

My personal opinion is that a good management team will have the following basic traits:

  • Excellent, upfront, and honest written and verbal communication
  • LOTS of experience in project management
  • Enough technical knowledge to understand the potential pitfalls, risks, and issues that the consultant team will encounter
  • Meticulous, detail-oriented nature
  • Constant anticipation and pre-planning
  • Tact and the keen ability to read people well (and react professionally)
  • Works well under pressure

Side note on Project Managers: although a PMP certification is a plus, I do not think it is a requirement. This is an area where street smarts overrule book smarts (again, in my opinion). Also, not all project managers need project plans. I’ll probably get flack for saying this, but Microsoft Project is a beast. It can help steer a project in the right direction, but beyond that, it is just an organization tool. The real skill is the style and finesse that the project managers bring to the table.

Architects

The Architects are the “cream of the crop” at consulting firms. They can also be divas. Architects are paid well and I’ve noticed a distinct pattern of consulting firms turning a blind eye to their less than perfect antics. They generally have 10+ years of experience, although I’ve seen successful Architects with less experience.

The definition of an Architect varies from firm to firm. But the commonalities I’ve noticed include:

  • Being stretched across multiple projects (and are therefore not engaged full time and/or from project start to finish)
  • Strong ability to lead both consultant and client teams
  • Fantastic selling skills
  • Great written and verbal communication styles
  • Industry thought leaders
  • Natural mentors
  • Excellent experience in what they do and know
  • Work well under pressure

A good number of Architects also have large egos and can be argumentative and defensive if they are not listened to or are questioned. I guess you take the good with the bad. Architects are in their position for a reason and from what I’ve seen…they really do know what they’re talking about and have a wealth of experience to draw from. They are your bread and butter technically.

Required role on a project? Yes. Plain and simple. This role may not need to be full-time, but I feel that it is necessary.

What to look for: I’ve found the following traits to be most helpful:

  • Excellent, upfront, and honest written and verbal communication
  • Well rounded technical experience, with depth in several technologies
  • Enough project management knowledge to understand the potential project pitfalls, risks, and issues that the consultant team will encounter
  • Constant anticipation and pre-planning
  • Great ability to translate technical speak to non-technical people
  • Natural ability to mentor and train

Senior Consultants

Senior consultants are referred to as “Senior Consultant” – I really haven’t seen this title stray at the firms I’ve been with. Depending on the company, they usually have 5+ years of experience and have been “around the block”. They may have deep technical expertise in a few areas or a wide range of skills. They are not architect-ready, but they may stand in for the Architect while they are offsite. Some act as the Project Lead or take on the duties of the Project Manager. Some Seniors may never want to be Architects – they may shy away from big team leading (and the inevitable accountability that comes with it) and prefer to do the “doing” instead.

Required role on a project? Not always. Project budget and size are always a factor.

What to look for: In a nutshell, Senior Consultants are more experienced Consultants (see next section), but the distinguishing factors are that they can be left to their own devices and can lead small teams.

A good Senior Consultant has the following traits:

  • Extensive knowledge and experience in 1+ technologies
  • Works well without supervision
  • Can lead and direct teams (but not extensively on a project)
  • Effective, honest verbal and written communication
  • Knows when to follow and when to lead

Consultants

The Consultant is a bread and butter role on any large project. (Insider’s note: they also make the most profit for a consulting firm.) They have less experience than most of the other titles at a firm, but they know more than your average business analyst.

The Consultant has 1-5 years of experience. This role may require supervision and guidance. Their technical knowledge will be limited, but better than someone in the corporate world.

Required role on a project? Most of the time, but again – project budget and size are a factor. Consultants have a lower cost factor associated with them, so they fill gaps well when it comes to project budgets.

What to look for: Since these guys generally have less technical expertise, you should focus, instead, on the following traits:

  • Decent experience in at 1+ relevant technologies (but at an intermediate level, not beginner)
  • Strong technical or business apptitude
  • A good understanding of how projects work
  • Ambition and an eagerness to learn
  • Lack of a big ego
  • Willingness to share information with others

Junior Consultants

The Junior Consultant is the lowest level consultant at a firm. At most firms, the “Associate”/”Junior” Consultant has little to no consulting experience or little to no experience in the work place (they may have been recruited straight out of college).

Required role on a project? Not always. Project budget and size are a factor. Also, not all consulting firms hire Juniors. They have the lowest cost factor associated with them.

What to look for: Juniors are great to have on a project. Most of them are young, so they bring a certain level of naivety and energy to a project, which can be refreshing. (Sidenote: They can also make you feel old.)

Since these guys generally lack technical expertise, you should focus, instead, on the following traits:

  • Ambition and an eagerness to learn
  • Lack of a big ego (most Juniors have some ego)
  • Willingness to share information with others
  • Strong aptitude for technical matters
  • Great documentation skills
  • Willingness to do the “gopher” tasks

Infrastructure

Referred to as Infrastructure or Technical consultants, this is a very different type of consultant. They are usually responsible for installing the software and/or spec’ing out the hardware. Their expertise is geared towards networks, operating systems, software optimization, and hardware. They are integral to existing client IT/IS/administration/support structures. Infrastructure consultants have a very short life on projects – they will be there in a full or part time capacity for a short time, usually just 1-6 weeks. They usually cannot have an intelligent conversation about software implementation – that is left to the remaining project team members.

Required role on a project? Depends. If you are a client trying to install the software yourself (yikes – God help you), then you may not need them. I would recommend hiring these experts to do your installation, but you should do the research first and go with a reputable company that has tons of experience.

What to look for: Because this is a different breed of consultants, I would recommend the following characteristics:

  • Thorough written documentation of efforts
  • LOTS of experience with software installations
  • A meticulous and detail-oriented nature
  • Excellent support network to turn to when there are problems (there are almost always problems – every environment is different)
  • Works well under pressure

So, there you have an in-depth look at the players on a consulting engagement…at least my 2 cents worth. Although some of you out there may disagree (feel free to comment with your thoughts), this is my personal experience over the years.

There is one thing that must be said before I end this post…I have yet to be on an engagement where all of the planets aligned and the entire project team was made up of perfect consultants in each role. That is not reality. Therefore, if you are reading this post, taking notes, ready to unleash harsh interviews onto your upcoming consultants…basically hoping to fulfill a utopia of sorts – I’m going to burst your bubble right now. Life doesn’t work that way. BUT…you can get a fantastic team, even when a few of the consultants have hang ups, quirks, or inexperience. There is something to be said about the team dynamic and how it can win out over the perfection of individuals. I have seen that scenario played out more times than I expected to over the years…and it’s beautiful.

Cheers,
The Traveling Consultant

Advertisements

Read Full Post »

To follow-up on an earlier post, I decided to include information below that describes, in detail, the different phases of a typical project. Please note that the below information is specific to the niche software consulting I have been exposed to in my career, and may not apply to every type of consulting project.

Most projects are divided into phases. For full-scale projects, the phases I have seen in my consulting career include five:

  1. requirements
  2. design
  3. build
  4. test
  5. roll-out

The requirements phase includes gathering the high-level business requirements and documenting them as a starting point: “here’s what we thought you said you wanted“. Some consulting firms choose to include technical requirements (specifics on the software customizations) in this phase as well – it depends on the company’s philosophy. Some members of the project team may be full-time during this phase and then part-time or off the project during the remaining phases. Usually this phase concludes with a requirements document that requires sign-off by both the client and consulting firm.

Next, the design phase includes taking the requirements phase to the next level – refining the business requirements and adding in detailed technical requirements: “ok, here’s what you really need and here’s how we’re going to build that“. The consultant team starts to build up during this phase, and the technical design of the solution is really hammered into. This phase should also conclude with a design document that requires sign-off.

The build phase includes building out the technical solution, in iterative phases: “here’s the tangible solution based on the requirements and design documents“. This phase includes the bulk of the project team, as many hands are needed to complete the work. Managers are crucial during this phase – issues arise the most during this point and need handling. This phase will conclude with a fully built (but not fully tested) solution.

The testing phase is one of the most important phases, and also the most overlooked: “let’s try to break it!” Consulting firms and clients both underestimate the time needed for fully testing the new solution, and usually for budgetary reasons. They forget that the testing users need to be trained on the software if it is new, and a testing environment will need to be set-up with its own security and dummy data. In addition, time has to be built in for the fixes and workarounds that will come out of this testing. Bottom line: the less testing done up front, the more problems down the road. When I’ve personally written project contracts in the past, I have padded this particular phase.

A side note (as this is a topic near and dear to my heart)…there are 5 possible types of testing that should be attacked when rolling out a new solution:

  1. unit testing
  2. data validation
  3. performance testing
  4. system testing
  5. user acceptance testing

Unit Testing only involves the consultant. This is the testing the consultant does when building out the solution – checking calculations, moving data, etc. Data Validation is usually completed by the client – verifying that the source data matches the target data. Performance Testing can involve a group of users all stressing the system at once, although this usually doesn’t mimic real performance scenarios. Or special software (i.e. Load Runner, Win Runner, etc.) is used to mimic the maximum number of concurrent users stressing the system. This testing is completed after the solution is fully built and tests how the system performs in the server/client environment with a bunch of users on it. System Testing involves the consultants and IT – it is an end-to-end test of all source and target data systems and processes. Finally, User Acceptance Testing (the testing that clients put the most emphasis on), is completed by the client and involves a group of testing users – running through a set of scripts that mimic a set of use cases.

Testing is so crucial to the success of any project, but for whatever reason is given the least amount of attention.

Finally, the roll-out phase includes “Go Live” – the official launch of the new solution: “ready for use!” Go Live is the deadline that the consultant team lives and dies by. This phase includes the launch date, user training, knowledge transfer of the inner workings of the solution to the new system administrators, and a small post-Go Live support phase. The consultant project team may dwindle down to only a bare minimum during this last phase. This is the conclusion to most projects and involves a final sign-off.

So, there you have it – the explanation of the general project phases. Not all project phases apply to all projects – there are projects that don’t follow the full project life cycle: sometimes consultants are brought in to relieve an administrator that recently quit and some projects are strictly assessments (a review of a particular business or technical issue that results in a 5-phased project). However, if you’re lucky you will get to see a full project life cycle from start to finish – the sense of completion on a good project is like achieving Nirvana…

Cheers,

The Traveling Consultant

Read Full Post »