Flex Consulting Chronicles #1: You are NOT a Contractor

Preface

The following is a set of articles relaying my experiences in Flex consulting with the hope they will benefit others.  While they include general consulting advice, they are specifically geared towards Enterprise Flex software development consulting.  I try to compare and contrast with contracting to give context.  While it’s mainly focused on Flex, there are the occasional Flash references as well.

Consultant vs. Contractor

There are 2 camps: those who believe contracting and consulting are the same thing, and those who do not. I believe they are two different disciplines.

A contractor writes code for another company. A consultant does more than just write code; she does the typical consulting process:

1. Listen to the client’s problems
2. interview project members by asking questions
3. investigating project requirements, design documents, code base, and project tracking records
4. write up a plan that contains a set of solutions to the client’s problems, and present it
5. implement the plan

Consultants can be contractors; they can be called upon to be team augmentation, or the team itself to build the software, hired specifically for their software development & leadership skills.  While contractors can work for both big and small companies, consultants typically work for only large/Enterprise companies.  This is because the large problems that require a consultant’s skills are found in larger companies, and in turn they are capable of affording the consultant’s rate.

Types of Consulting Gigs

You’ll notice from step #3 in the above mentioned consulting process that consultants are typically brought into an “existing” project.  This can be one that is just starting, underway, or is just completed.  The following 5 are the most common type I’ve encountered.

1. Confirm Our Confidence/Trepidation’s

The client wants to ensure the existing team is “on the right track”.  As a 3rd party, the client is either looking for your vast expertise to confirm the current plan of attack & team skill set is enough for success… or they just want your opinion.  A lot of times this is to confirm what they already know, but don’t necessarily let you know they know.  This is called the “Confirm Our Confidence” or “Confirm Our Trepidation’s”.

2. Why are we sinking?

The project is clearly off track, but no one knows the root cause(s).  The client is looking for you to tell them why.  This is called “Why are we sinking?” or “Save our Flex Project!“.

3. Ensuring It All Goes Smoothly

The client isn’t getting enough traction on the project, and want a heavy hitter.  Since a lot of top talent typically doesn’t do contracting, you often can only find the heavy hitters as consultants.  Other times, the client merely has budget, and decides to reduce their risk by bringing on a senior architect/developer from an existing firm that is known for producing quality work.  Assuming the project requirements are far below the challenge the consultants typically face, there should be no problems completing it, right?  This is called “Ensuring It All Goes Smoothly”.

4. The Last Mile

The client has just completed a project, and it doesn’t work.  They’ve invested a lot of time and money, and are angry/frustrated/confused why there are so many problems.  Sometimes they even try to convince you that it “just needs some minor bug fixes” and it’ll be fine/good enough for their needs.  They call upon you, since apparently you’ve successfully completed many projects, to figure out how to get them to, and past, the finish line.  This is called “The Last Mile” project.

5. Last Minute Replacement

Making software takes a team.  On every team you have one or more senior developers; the developers who “have done this before”.  Without their leadership, projects can get really bogged down, and often fail to launch on time, or at all.  Some clients for one reason or another, often under not-so-good-circumstances, will have lost their main architect or senior developer.  With no one else on the team who is capable of taking an architecture/leadership role, companies will look for a replacement to ensure the project stays on track.  You are then put in the position to learn a code base you didn’t architect, don’t know, and may not agree with.  You must do this in a short time frame, integrate with the existing teams, and learn their processes.  It’s often done for entire teams, not just 1 individual.  This happens when another firm has a fallout with the 3rd party company/firm for whatever reason.  This is called the “Last Minute Replacement”.

The Consulting Process

As you can see from the above process, and the types of gigs, they aren’t your typical “software development”, even though you do “software development” during those gigs.  These are not mutually exclusive.  Some clients use Agile, some Waterfall, some mish-mashes, and some no process at all (Process.COWBOY_CODING).  Let’s go through the consulting process first, since that part is ALWAYS the same regardless of client.

Step 0: Who’s my boss and define success?

This one I learned from Tom Link over at Universal Mind.  There are 2 questions you should always ask the client, AND get answered, before you start any consulting project.

First, who’s my boss?  Second, what would make you happy once I leave?

For contracting gigs, it’s pretty clear who your boss is; whoever contacted you.  Often project managers are the ones responsible for both the hiring, and managing the remote contractor, in this case you.  Therefore, if a designer emails you comps, and you don’t agree, you usually take it up with the manager via email/phone.

In consulting, it’s usually not the simple.  Often times you’re dealing with large/Enterprise companies.  You may have some random Director of blah blah East Coast operations come in and start making demands.  Seeing others jump, you may get the impression you should jump too.  You shouldn’t.  If she isn’t your boss, you shouldn’t do what they say.  As a consultant, every minute of your day is costing the company who is hiring you a lot.  Anything you do that deviates from your original assigned goal is not only unethical towards the company you are working for, but could potentially cause you not to get paid.

The great thing about being a consultant is you can say and do things an employee of the same company you are working for could never get away with.  Feel free to ignore someone telling you what to do if they aren’t your boss.  Obviously you need to treat these situations with tact, but if you just remember you may piss your real boss off and not get paid, it’s easy to stand firm.

Regarding defining success, it helps keep in mind what you were originally hired for.  If you were originally hired to help enable the team to succeed, and you hand-hold them to victory, technically you failed at your job.  You can potentially breed resentment by those you were supposed to empower to succeed.  Remember, you’re not a contractor, but a consultant, a professional specialist hired for a specific purpose: to offer a plan of attack, not actually implementing that plan.  While you may feel good creating a brand new video player for the client, they might not like the bill when all they asked for was you improve their existing one.

Knowing who your REAL boss is keeps you out of trouble.  Knowing your true objective keeps you focused amongst the chaos that WILL ensue around you.

Step 1: Listen to the client’s problems

When you are looking for a new contracting gig, you are looking for a client who wants you to build something for them.  “I need a Flash widget”, “I think I need a website that does X”, or “This video player needs to have these custom features”.  Inheriting other people’s code to fix isn’t very profitable, and is often a miserable experience.  Therefore, a lot of contracting where you’re “building things” for clients is a lot of fun, and often a positive experience.

Consulting often times is done under negative circumstances.  “We were building a Flash widget, but ran into trouble”, “We don’t understand how a website could be so challenging to build with $80k worth of development over 4 months with so little to show for the time and money”, or “our video playback performance is very poor”.

You first, and foremost job as a consultant is to listen.  You need to get the whole story, and you NEVER get it during the hiring process.  A lot of the times the story you get is only the tip of the iceberg, misleading, or just wrong.  This isn’t to say it’s always wrong; a lot of times you do get an accurate assessment from management.  The key here is you need to get the details so you can ensure whatever plan you create to fix it is the RIGHT plan.  Creating a plan to optimize the client side code to improve performance when in reality the back-end servers just never work consistently, nor was any thought put into optimizing the messaging format makes you look incompetent, or trying to take advantage of the situation.  Part of your plan could include allotting additional time to investigate the service layer’s issues, and come up with a plan to fix them should they have issues.  [Did you catch that?  I just said “plan to plan” in so many words.  Just seeing if you’re awake!  –JXL]

There is also the potential for negative pretense about your arrival that can affect the story you get.  While you may perceive the management as good for caring enough about a troubled project to bring an expert in, those on the project may hold resentment towards them, and displaced aggression towards you.  Therefore, you may get answers to your questions colored with emotion, or nothing useful because emotions are so raw.

The point here is to ask questions, investigate, find out what’s really going on.  The information you garner will enable you to formulate an effective plan to fix/solve the client’s problems.  This process doesn’t necessarily stop, but by the time you are presenting your plan, you know what the problems really are, and how to fix them.

Step 2: Interview project members by asking questions

Asking questions.  It’s the same thing you’d do if you were a contractor trying to build software for the client, or a consultant trying to save a project from doom.  What back-end am I hitting and what is the data format we’re exchanging for both the request and the response?  Where are the design comps?  Why were they created like this?  Who is the designer and is there a nearby open window to throw them out of?

You need to learn who is on the project, who those people are, and what makes them tick.  You need to learn how they act, and how they acted under the circumstances of the past to better predict how they’ll act in the future.  You need to learn why those decisions were made, and truly understand what the the ramifications of those decisions were.

The point of this step is to figure out what the true problems are by talking to the project members.  Your goal is to glean as much information about the project as possible.  From that information, you can formulate a relevant plan of attack to help solve them, one tailored so that it will work in the particular organization you are working with.  Notice the keyword “help” in the previous sentence; often times in Flex/Flash consulting, you are the one who will help implement the plan.

Step 3: Investigate the designs/code/requirements

While this is often done in tandem with step 2, a lot of step 3 can be done alone with questions posed in emails and phone calls.  Getting a team member to walk you through the code is something you’d do in step 2, while walking through yourself and getting familiar with it is step 3.

Here you start digging in and ask questions like “Why did you all choose this framework?  Why not this other framework instead?  Did you know about X, Y, and Z when you started down this development path?”  Your goal here is to get history on an existing code base or project plan.  ALL code bases have a story.  Code is born from the 4th dimension.  Software developers will often debate about best practices as if code existed in the 3rd dimension, but it does not.  All code has a reason the way it is.  It came from a certain set of decisions that shaped what it is today.  These decisions where made under certain circumstances.  Those decisions were made by certain individuals and teams who were in those circumstances.  Context is key here, and once you can tell the story of the code, you’ll have a good understanding of why it is the way it is.

An example is, “The code base is a large Flash website created by a 3rd party agency.  Some if it is a professional, simple, and easy to understand custom MVC portion.  The code in the associated FLA’s, however are not.  The reason for this is that a senior developer was brought on initially to setup the website.  Apparently, this senior developer moved onto other projects, and junior Flash Developers were brought on to finish the more GUI related tasks.  This worked out well for the agency since the junior developers didn’t have to know anything about the framework; they just wrote 1 line of code on the root timeline.  The downside is that while the framework was flexible, portable, and provided a good foundation for the code, the FLA’s themselves, all 32 of them, were basically useless to re-use.  The amount of time spent figuring out, and attempting to finagle already badly written code to work would not be worth our time.  Since the current redesign plan is currently in flux, and the client now owns the code, we can work with the in-house team to start building a firmer foundation on the View portion, and create easier to work with FLA’s while still re-using the older FLA’s assets.  The Model and Controller portions that run the website can remain the same.”

You’ll notice I’ve already started to form opinions about a possible plan of attack whilst writing the story.  That’s the point; you’ll recognize possible scenarios on what your team can do to make the most in the current situation given your current resources.  From there, you just need to document it.

Another example, when you look at a Cairngorm code base and go, “Why the F$*^ didn’t these guys build this using Gaia!?”, you know’ll how to answer your own question: the team was an existing team of server-side Java developers doing Flex for the first time, and the small size of this project seemed like a good test case for seeing how Flex performed in their department.  Flex was specifically created for developers because Flash never took off in the software development world, and Gaia currently doesn’t work with Flex.  That, and they perceive this “website” as an “application”.

This becomes more important when you start to recognize problems not just in the code, but in the development processes in the team, and perhaps the client’s organization.  A lot of times the code’s poor state is a direct result of those managing the developers; ie they are setup to fail.  Other times, 1 developer is preventing the others from succeeding.  We as coders sometimes get too focused on the code, when the code is the last thing that can positively affect itself.  Unfortunately, it’s often easier as a good coder to merely fix the code because you don’t think you can fix management or their processes.  Often times, this is what you must do.

Now, a lot of times you may think, “Oh man, I hate this framework, I’m going to re-write this whole thing in my other favorite X-framework, and then we’ll be able to make progress”.  If you ask around, though, you may find that the team had specific reasons for doing so.  Hiring Cairngorm developers is a lot easier than hiring PureMVC developers, for example.  Maybe the team didn’t know the other frameworks and decided on the one they chose because they all participated in company-paid training for it.  Or, maybe the team claims they know other frameworks, but they really don’t.  Training is often an option and sometimes a crucial part of consulting, but again, you need to remember what you were hired for.  Sometimes, the code base is just too big, and you might not have the resources to port it in a reasonable time frame without sabotaging productivity of the rest of the team.  Worse, you port it, the app has “more” bugs because it’s fresh out of a major re-factoring effort, and the client is wondering why they hired you.  For the big code bases, you often need to figure out how you can make the most with what you got.  That phrase, for me anyway, often never happened in the Flash world, but happens ALL THE TIME in the Flex consulting one, merely because the projects are so large.

Step 4: Write up an Implementation Plan, and Present It

Based on your talking with team members, and doing your own investigation into the code and design comps, it’s time to create a formal plan.  There are 3 goals for this.  First, to formally show the client what your professional recommendations are.  Second, while writing, you help solidify what those recommendations are now that they are written down formally.  Third, if you get caught up working on other things during the implementation phase, you can remember what your true goals were, and re-align since you can refer to the document.  To get to this point in the process usually takes me 2 to 3 weeks on-site with the client.  I’ve done it in 2 to 3 days before, though.

The plan can follow the typical “tell what you’re going to tell them, tell them, tell them what you told them” format.  The plan is often a document that has 3 sections.  An executive summary, problems & solutions, and conclusions.  Your executive summary is a 4 sentence paragraph summarizing as high level as possible what you were hired for, what you found, and how you plan on fixing it.  This is both for management to get a quick of assessment, and it’s also great when they forward to true “executives” who don’t have a lot of time, and will not read things.  Having a succinct paragraph that makes it “appear” like you did your research and know what your doing makes it easy for managers to copy and paste that into emails or other reports for example… hence the name, “executive summary”.

The problems and solution section states what problem(s) you found, and each possible solution(s) to each problem.  A problem cold potentially have multiple solutions.  Often solutions to a problem aren’t very straightforward, and you want to give management options.  Like Darrell Ross once told me, your goal isn’t to spend your client’s money, but rather provide transparency to the problems at hand, with well thought out solutions, and allow them to make the decisions that directly affect their project.

Finally, the plan document needs a conclusion.  Here you summarize your succinct, professional assessment of the situation, any other high level risks that need to be made known, and your desire to move forward highlighting the positive results of doing so.

Once completed and proof read, you present this to your boss.  Often times it’ll just be your boss, and no one else on the team.  If you’re a good consultant, you’ll provide the raw truth of the situation, and your honest assessment may offend others.  The client hired you to get the real truth, and you are obligated to provide this; this isn’t personal, it’s business.  This can be done over email, phone, a more formal presentation with slides if others are present who either don’t have time to read the document, or need some high level context on what you are consulting about, and what you plan to do to help fix things.

Finally, the document, as well as communicating it’s contents effectively, legally shows you attempted to provide value to the client vs. stealing their money by slacking off.  Remember, consulting is often done in really negative situations; having a paper trail is good CYA (cover yer arse).

Step 5: Implement the plan.

Also known as, git-r-done.

Contracting?

If you’re a contractor, you may have read a lot of the above and said to yourself, “I already do a lot of that.”  Perhaps you do.  Contractors are often pulled into consulting situations because they are a LOT cheaper than consulting firms, and the contractors don’t realize their monetary worth.  Sometimes only 1 individual is needed vs. multiple consultants.  That, or a firm isn’t found/known to the client.

Mostly, though, contractors are hired to build things, fix things, or help on things.  Consultants are hired to give their professional opinions on existing projects, fix really large, screwed up projects, or help on larger endeavors with multiple consultants helping.  The 2 main differentiators are scope of the project, and amount of emails & documents you write.  If you have the capability to re-write the software from the ground up in 2 weeks, don’t write documents multiple times justifying your efforts, nor participate in meetings with various stakeholders who are all mad… you’re a contractor, not a consultant.  That, and if you don’t charge consulting rates.

Conclusions

Consulting is the disaster recovery of the software development world.  It sometimes has a negative connotation in larger enterprises because by prolonging the problem a firm can make a lot of money.  Others view the client’s resistance to positive change as a no go, and instead choose to let the client fail, THEN come in to help them up.  To me, consulting is a natural progression from being a contract software developer.  You’ve been in enough negative situations, you recognize how to get out of them.  Convincing the client of this, as well as getting them to actually do it, is where it’s challenging.

Software development is hard.  That said, there are a lot of development shops out there that can work with larger companies to create wonderful solutions.  What’s more valuable, and challenging, is working with larger companies to escape horrible situations.  You get into this line of work because either you love the challenge, like the appreciation of clients who are saved from certain doom, or you just fell into it as an “unnatural” career progression like I did.

A lot of times, you and you’re fellow consultants may be very skilled compared to others in your industry, yet you’re given way less time than needed, with an already existing problem code base… and you’re expected to work miracles because “you’re so good”.  …and then God invented alcohol.

If you are an independent software developer interested in getting into consulting, the easiest way to to start is to join an existing firm.  I won’t name names, but there are a few firms in the Flex industry that do this kind of work all the time.  Beware of evangelists/owners from said firms that claim you’ll “work with clients to create engaging solutions, building awesome Flex applications from scratch”.  They are all full of shit.  If you’re any good, you’ll be put in the worse situations imaginable.  Clients like you when you build something awesome for them.  They like you more when you prevent their project from going up in flames… and are often more willing to part with bling.  Consulting firms know this.

To be a consultant, you typically are brought into troubled projects, and use the consulting process to help those projects succeed.  This includes listening to the clients problems, investigating the code, writing up & presenting a formalized implementation plan, and executing the plan.  Everything else is based on your experience, intuition, and luck.