Midwest IT Survival

Over Architected?

First off, I am by no means an “Agile” (nor even “agile” with a small “a”) software development expert.  There are many more individuals out there that are way more experienced and in a much better position to speak authoritatively about the Agile methodology and its associated principles on driving efficient and effective software development.  A few blogs where I consistently find great Agile perspectives are included at the end of this article.  But as I’ve participated in Agile and agile-like development efforts over the years, I’m finding an interesting pattern.  Agile and agile-like approaches have a positive by product of reducing the occurrence of over architect-ed software solutions. Over architect-ed solutions put stress on the delivery of a software application project as well as drive up the cost of software development and maintenance, in general, disproportionately to the business value produced.

As an example, a sample development effort starts out with:

Product: “We need a super widget in the product by next release, can we have that?”

Project: “We are going to need detailed requirements for the super widget in order to start developing it.”

Product: “Oh, it needs to be able to interface with the dry cleaners to know when it is time to pick up the laundry as well as make coffee for the customer before they get out of bed in the morning.  Basically the same features as our competitor’s recent release, but with these additional benefits. <Or some other description that is actionable at a high level, but lacks the detailed requirements needed to feed a development team with actionable development tasks>”

Development: “Ok, we’ll get started since we don’t have much time before the code freeze for the next release.”

… Time goes by …

A project status meeting occurs sometime in the future.

Product: “So, where are we with that super widget?”

Development: “We have the basic framework setup but it isn’t going to have all the features working by the next release.”

Product: “But I thought …”

Development: “But you said …”

Project: “What happened?  How come we are X days from the code freeze and we don’t have a viable solution?  I thought …”

Now sure, this isn’t the most perfect example of capturing how the requirements drift between stakeholders leads into an over architect-ed solution, but hopefully you get the scenario.  Or possibly another example would be when a solution is developed and released into the production environment.  Extending the example above, weeks later, when enhancements, tweaks or feature extensions are requested, a tense conversation occurs around:

Product: “But I thought the super widget would do X?  How come I am hearing it will take 30 hours of development to get X?  The testing cycle is already elongated due to the complexity of the super widget thus I thought it included X?”

Development: “But we said that the framework would support X, but we never said X would actually function without more development!  We developed the super widget to do W, Y and Z but only stubbed out X.”

Project: “But according to the requirements, it says X should be …”

And yes, an argument can be made that if:

• more effective requirements gathering occurred
• more effective project management captures more depth of what would be developed and available when
• more effective product management defines a more exhaustive product feature road map that more clearly outlines what would be available and not available when, feature-wise

… These problems wouldn’t have occurred.  But the nature of an agile-like approach puts a tighter focus on all the stakeholders:

Product: They can share the “overall vision” of what they ultimately desire the product to do, but they are forced to consider what they really need within the shorter duration of the agile-like release schedule.  Thus, product walks away with a clearer picture of what they are really getting in the next release.

Development: They get the benefit of the product’s “overall vision”, yet, they get to quickly dive into the critical features and start the dialog of how long different feature components will take to develop.  Thus, development knows exactly what they need to do now for the next release, yet they benefit from knowing where this product feature is going in the future.

Project: As long as they keep the product and development stakeholders talking about granularly defining what needs to really be built by when, the project management function has much greater clarity into what is going on and what details to track.

From what I am observing, all of the above create a stakeholder forum of information sharing that reduces the likelihood that an over architect-ed application will get developed. Most importantly, instead of leaving the feature set open and vague enough to allow a creative and motivated development team to start building and building and building only to re-surface with a highly complex solution to a loosely defined problem or need, it brings more cohesion between what is really needed first.  Once the “first” has been built, the “seconds” and “thirds” get built inline with the product roadmap.

In researching this theory, I wasn’t able to find any articles that linked agile-like development efforts to a direct reduction in software over architect-ing.  This article entitled “Agile Architecture: Strategies for Scaling Agile Development” had some interesting content on baking architecture into an agile-like effort.

Anyone else have any direct experience in agile-like compared to waterfall-like development efforts yielding less application over architecture?  Can anyone share any links to good web articles on this topic?

Agile related blogs I follow:

David’s Software Development Survival Guide

http://softwaresurvival.blogspot.com/

NOOP.NL

http://www.noop.nl/

Software Project Management

http://blog.brodzinski.com/

fragile

http://fragile.org.uk/

Regular Geek

http://regulargeek.com/

Critical Results

http://criticalresults.com/

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as an engineer that has a role to play on an IT project.

In the previous article, the concept of a “pre-task” was introducing a gap in the project plan and introducing gaps into the plan causes panic.  Thus, how can you redirect this panic to work for you?  That is were the ability to introduce a gap or a “pre-task” from the example in the previous article that redirects the panic on to another individual or entity while at the same time, implying the gap should have been already accounted for because everyone knows it is a required tasks works.  Breaking down the previous example:

How does a pre-task help me?

“…I can’t finish until the Architect signs off on my design document” introduces a gap in the plan that doesn’t involve or imply more work on your part.  Rather, it brings in a task that is a barrier for you to complete your task.  Thus, and here is the selfish benefit, this technique allows you to work on your task without someone hovering asking every five minutes … “is it done yet?  How about now, is it done yet?” as project managers tend to do.

“All designs must have Architect sign-off” is the follow-up sentence implying that it is the project manager’s job to know this standard operating procedure or process.  Thus, it isn’t your job and thus you can take no blame for not having this step in the plan from the beginning.

In summary, whether you find yourself with too many chiefs or too many indians, using the tools above should help you succeed in your role on a project.  Now if you have read this far and are thinking to yourself, “geez, this sure sounds like a lot of work above and beyond doing real engineering work.” my response is yes, it is.  And yes, none of it is seemingly appealing to the engineer that just wants to do engineering work.  But, in my experience, I have seen, time and time again, the good natured engineer get himself, his boss and his team in hot water because all the chiefs were pointing the finger of blame squarely on the good natured engineer that became the almighty reason for the project delay.  The finger is pointed regardless of all the prior missteps that get conveniently forgotten in these scenarios or have already been covered up.  To better position yourself not to get caught up in these nontechnical exercises with chiefs, it pays dividends to invest some time understanding what the formal and informal processes are in relation to your project role and get into the practice of always having a pre-task in your back pocket to use when chiefs are starting to dig into the project tasks.

Key points from this series of articles:

• Know your role on the project and ensure your boss is in agreement.
• Always have your boss in 110% support of your performing tasks/functions outside of your traditional role
• Have a working knowledge of the official project and engineer processes leveraged by your company
• Always have a pre-task ready to articulate when ever possible to create that external dependency on any tasks you are performing

When to insert that upgrade dependency

I think one of the greatest challenges in IT is to get an IT centric effort off the ground and executed to completion.  I’ve been faced with this challenge over the years and have adapted different strategies based on the circumstances to varying degrees of success.  In this article, I’ll outline one which involves linking a sponsored project in flight requiring some technical solution from your team to an upgrade or enhancement your team wants but is struggling to implement on your own.

As mentioned in the prior article, if you are providing some IT services back to the rest of the organization, you must have some formal mechanism to aide in prioritizing the work requests.  If a project is of a high enough priority that it needs to be accomplished and your team has a role to play, consider creating a plausible dependency on meeting the project requirements via the upgrade/enhancement you want to implement.

I’ll take a stab at a typical requirements gather conversation to explain:

Project Manager: “Boss, it is my understanding that your team provides widgets that interface between the FlimFlam system and the billing system?”

Boss: “Yes and my understanding is that this project requires a widget to take the ABC format that comes out of the FlimFlam system and convert it to the XYZ format so it can be fed to the billing system, right?”

Business Analyst: “Yes, that is correct.”

Boss: “Well, I checked with my team and we have two options.  One, is we can directly develop the conversion widget in the current product version we have and that will take 20 days and there will be extensive testing and the possibility for a high number of defects due to the custom coding.  The second is we can upgrade our product to the latest version which contains native support for converting ABC to XYZ.  Thus, the 20 days becomes 1 day to configure the new product.  The new product has been out for six months and used by a number of other customers thus it shouldn’t have any serious defects.  The catch is we have to regression test the five other widgets currently in production.  Our recommendation is the second option.”

And just like that, you’ve articulated a business case that strongly suggests an upgrade you have been wanting to implement but couldn’t get all five interfaces tested and signed off.  This sixth interface project effectively completes both objectives: yours and the projects.

Hopefully you have done your homework and are seriously confident that the upgrade indeed will meet the project needs even if the “native support” is stretching the truth just a bit.  The real key is that you can realistically meet the project needs within the alternative estimated timeframe.  Once the project gains momentum and is marching down your road of upgrading and testing versus custom coding, it is next to impossible to switch the decision as long as you are trending towards meeting if not exceeding the other estimate.  One of the more difficult IT centric challenges is getting another group to test their technology that interacts with your technology when they have no reason to do so except for your need.  This approach uses the priority and urgency of this new project to drive that testing.  “Guys, we wouldn’t need you to test but this other project is forcing us to change thus we need you to validate …”

What happens if they build momentum and go against your recommendation?

The subtle power of “recommending” one particular course is one of risk ownership.  If the project accepts your recommendation, then you own the risk of not meeting the projects needs.  If the project rejects your recommendation for an alternative, then the project now owns the risk of the success and/or failure of your work to a significant degree.  How so?  Well, whenever the project comes back to complain about missed deadlines or quality issues, you have the immediate  response poised: “Well, you remember we recommended option A but you asked us to do B.  Had we done A, I believe we would be meeting your expectations.”  You have various permutations of that response as your get out of jail free card to the immediate complaint.  Clearly, if you enjoy your paycheck, you need to continue to make the project a success.  But, if the project as a whole starts trending negative, you are pretty much in the clear of taking a significant portion of the blame.

What happens if your recommendation turns out to be more complicated/time consuming than you originally thought?

This is where doing your homework comes in.  Before even recommending the upgrade/enhancement dependency option, you need to be extremely confident in your ability to meet expectations.  Going off new features and functions in release notes is a bad idea.  Working from some semi-formal product/solution testing and real engineering evaluation is a much better idea.  If your role in the organization is exceedingly intolerant of the risk failure, then I would venture to say go so far as the only open variable is the need for the formal testing signoff from the external groups.  The closed variables would be up to and including having already technically tested and confirmed the external group owned systems will work in formal testing scenarios (via the systems themselves and/or a stub of their systems touch points with yours).

The ability to link an upgrade or enhancement to an in flight project gives you the ability to help the project succeed as well as accomplish a goal on your list at the same time.  The keys are to be able to plausibly justify the upgrade approach is better than an existing solution coupled with being extremely confident based on actual testing that the upgrade will actually work.

Has anyone used this or a similar approach and had success?

How do I get this IT project started?

I think one of the greatest challenges in IT is to get an IT centric effort off the ground and executed to completion.  How many times have you been in a team meeting where the dialog went something like this:

Boss: “Anyone check out the new enhancement to the project management software we use?”

Bob the Engineer: “Yes, according to the release notes, it now includes a bug tracking module that is as good if not better than that silly third party product we use.  Plus, it is now integrated with the enterprise QA reporting service.  If we upgrade then we can turn off that third party bug tracking software and decommission the server.  Plus, all the PMs can stop manually typing in their project details into the QA reporting tool rather, hit a but to automatically populate the QA tool.”

Boss: “Sounds like a no brainer to upgrade … but how are we going to pull this off?  We need some time to install the upgrade, import the existing data, training and cut all the PMs over plus put together a training guide or something for the business testers that currently use the old testing software … plus, probably a bunch of other details I am not thinking of at this moment.”

Bob the Engineer: “Yah, this would totally help people in the company get projects done quicker without all the manual bologna that goes along with tracking stuff.”

Boss: “No one else is really looking at this but us …”

So here you stand on the precipice of a significant efficiency gain to the organization’s overall project delivery.  So why can’t you just jump on executing this obvious, no brainer improvement opportunity?  If you are part of most “MidWestern-ish” IT organizations, you have a great (or not so great, but your have one) engine for handling the prioritization of business driven requests, but lack, somewhat, the ability to inject an IT centric request.  More than likely, your current prioritization engine would drop this upgrade to the bottom of the list which means no one is going to be able to work on it given all the other high priority business requests.

I’ve been faced with this challenge over the years and have adapted different strategies based on the circumstances.  In this article, I’ll outline one which involves converting the IT request into a business request devoid of IT buzzwords.

As mentioned above, if you are providing some IT services back to the rest of the organization, you must have some formal mechanism to aide in prioritizing the work requests.  [Warning: extended water flow metaphor ahead]  It is impossible for a finite set of resources (IT) to be handling an infinite stream of requests (the business) without prioritization otherwise the organization as a whole will eventually implode in on itself.  Whether it is the example above or a new low cost storage technology or a new development language of choice major revision, one way to get some attention in the proverbial fire hose of work coming at you is to get that work into the business request pipeline.

To accomplish this, besides digging into how requests can be properly formatted to formally enter the pipeline itself, you have to start converting the IT request into a business request.  For example:

IT Version:

• Upgrade the project management software from v1.0 to v1.5
• Decommission the bug tracking software and server

Business Version:

• Enable the overall savings of $12,000 and 240 hours per quarter per IT project by providing technology and process improvements to the project delivery process, total per year savings = $480k and 960 hours less a one time investment of 200 IT hours to implement
• Supporting Data:
  • Assumption = Overall hourly rate for PM and Testing resources working on IT projects = $50 (average salary + average HR overhead + facilities)
  • Current = Averaging 20 concurrent projects each averaging 3 months in duration require 3 QA reporting updates per week consuming 1 hour per update
  • Future = Automate this process to one click, thus 20 project * (3 months * 4 weeks)  = 240 hours saved and 240 * $n = $12,000 avoided per quarter
  • [If you can compute the guestimation of monthly savings on the hardware, depreciation, software licensing and data center stuff (power, cooling, rack space, etc.) of decommissioning a server, add that to the total money savings]

Now, your first reaction maybe, “geez, those two look radically different, how can they be focused on the same goal?”  The key word in the goal sentence that I chose was “convert” an IT request into a business request.  Sure, you can look at some software release notes and quickly run through a business case in your brain that says “heck, these new features are really going to help us get work done faster”.  But non-IT people don’t immediately draw the same conclusion that you just did.  Depending on different levels of non-IT involved individuals in the project prioritization process, any number of perspectives can be drawn from the IT version:

• Why do we need to upgrade?  What we have seems to work fine
• Update = spending money … I don’t want to have to try and explain why I approved spending more money
• I don’t immediately understand this request thus it can’t be that important, next item that I might be able to comprehend …

But what are the two universal business concepts that everyone inside and outside IT can appreciate?  Doing something that will save time and/or money.

Thus, how do you get some attention and focus on your seemingly IT centric request?  Answer = convert it to a business request that somehow legitimizes benefits the change itself provides back to the business.

Anyone tried such an approach and experienced success (or failure and why)?

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as an engineer that has a role to play on an IT project.

In the previous article two concepts were introduced to help you survive.  Now it is time for the most powerful concept, the “pre-task”.  As much as possible at all times, create the perception that you are waiting on something from someone else in the organization.  Make sure in every situation possible that the project manager or development lead or whoever is managing the checklist of project tasks believes someone else needs to complete their task before you can complete your task.

Not having a “pre-task”:

Sally the Project Manager: “So Bob, according to my plan, you should be working on that widget … are you done yet?”

Bob: “Um, yah, I’m working on it but I told everyone it was going to take me five days and this is day two.”

Sally the Project Manager: “Not according to my plan … it says you build the widget and then we start testing.  You are holding up testing.  I’m going to have to escalate!”  And rushes out of your cube before you can formulate a response.

Having a “pre-task” at the ready:

Sally the Project Manager: “So Bob, according to my plan, you should be working on that widget … are you done yet?”

Bob: “Um, yah, I’m working on it but I can’t finish until the Architect signs off on my design document.  All designs must have Architect sign-off.”

Sally the Project Manager: “Um …” <has no clue what that means but now knows there is a delay building> “I better go find our Architect on this project and get him or her involved”.  And again, rushes out of your cube.

Now, in this example, there are multiple issues generating confusion.  One is task duration.  The likelihood that someone actually recorded your need for five days to actually do work is very low.  I am continually amazed that the less technical a person is the greater the likelihood they will assume a technical task takes an amazingly short amount of time.  Another is the propensity for project managers or people whose primary job it is to track other peoples work are quick to react less than rationally when their plan gets messed up.  They have their plan and they remain rational when, as time goes by, the plan remains unchanged and tasks are sequentially marked complete.  But when the plan itself appears to have a gap, panic and irrationality can ensue.

Ok, why does someone whose sole job is to track a checklist loses their marbles when there is a missing tasks or four additional tasks need to be inserted somewhere?  A quick glimpse into the project manager’s world reveals their greatest value to the organization is in their ability to predict the future with their plan.  Based on the future date their plan indicates, all kinds of business-ish things could be set to kick off.  Thus, something as simple as a plan that says when a system upgrade will be deployed could also be the starting point for a marketing team to formally kick off a set of media ads, plus a customer training/education packet could be already in the mail with dates for when each customer will be forced to use the new upgrade system, plus an accounting group could be poised to show a drop in license costs (i.e., save big money) due to the upgrade, plus, some executive is counting on the license money savings making his departments balance sheet come just under a magical finance number that triggers a quarterly bonus.  Hence, when the upgrade implementation date starts slipping from a failure of the future predictor (aka. project manager) being accurate, all kinds of heat from all kinds of folks downstream from any of the technical work associated with the project can come out of the woodwork and come down hard on the project manager for giving bad data.  Hence, fearing such heat, project managers react in a variety of ways and some of which are not particularly 100% rational.

In the next article, I’ll outline how to use this panic to work for you.

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as an engineer that has a role to play on an IT project.  The previous article can be found here.

How to survive with too many chiefs or too many indians

First and foremost, make sure your role is clear on the project.  Make sure at all times you are executing the functions associated with your role.  If you are unsure if your role requires you to perform a certain function, ask around to confirm and if you aren’t getting concrete yes or no answers, confirm with your boss.  It might seem like you are annoying or bothering your boss but believe me, your boss would rather answer a 30 second role clarification question than sit in hours of meetings dancing around why someone on his team did or didn’t do a particular function on a project.

Second, if you have opportunity or are asked to perform a function outside the bounds of your role, consider all the angles before just up and completing the function.  It might seem cool to build the widget that connects the two systems together to allow the transactions to flow, but if that is not your explicit role, you might be putting your boss and your team in jeopardy.  How so?  Well, if you team is a support rather than a development group in the organization, you have just forced your boss to have more ownership in the system than he has been charged to have.  Your boss will be in political hot water when you are pulled back into the project make changes to the widget while other systems your boss is responsible for need coverage and you can’t be in both places at once.  The last thing you want to be doing is creating a headache for your boss when your boss has the most direct influence on your job duties and compensation.

Not all functions outside of your role are filled with danger.  Some are filled with opportunity for praise for helping the project move forward.  In the example above, there may not be a role that is supposed to build this widget.  Maybe the project is plugging all the technology together in order to test the final solution and someone didn’t realize these two systems needed a widget.  You could be the engineer that saves the proverbial day.  When everyone is patting each others backs when the project is successfully implemented and everyone is overly positive, someone could exclaim: “Wow, glad Bob pulled the widget out of his ear at the last moment, we thought we had a big delay on our hands!”  Yes, these moments are few and far between, but they do exist, they are fleeting, so enjoy them for the brief moment they do exist.  The key to pulling this off successfully, starting even before building a working widget, is to make 110% sure your boss is completely onboard with what you are proposing to do outside your role and the risks associated.  Be prepared for your boss to agree that you are completely capable of building the miracle widget, but because of company politics that if you tried to put them together in your mind would make you pass out, he asks you not to build the widget.  Don’t get discouraged if this happens.  There will be many projects and many opportunities to stretch your role and position yourself for exceeding expectations.  Learn from these rejections on how to better sell your boss on your ideas for the future.

In the next part of the series I’ll continue cover how to survive with too many chiefs or too many indians with one of the most powerful tools the “pre-task”.

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as an engineer that has a role to play on an IT project.  The first article in the series can be found here.

Projects where everyone knows their role on and the goals of the project are rare.  More than likely, the project you are about to join is top heavy in one of two ways.  The first is too many chiefs and not enough indians.  Like the proverbial saying implies, plenty of people taking about the work, defining the work, breaking the work into chunks or phases or milestones or whatever is great, but if there is no one around to actually do the work, you as an engineer or as a do-er is likely to get dumped on.  The second is too many indians and not enough chiefs.  Equally dangerous because the lure of a bunch of engineers doing cool engineering stuff without chiefs provide direction, priority and governance, time and costs are ripe of getting out of control.  The next section will cover each in more detail with tips on how to avoid the prospective pitfalls.

Too Many Chiefs

A project full of managers, project managers, business analysts, requirements documenters, technical writers, testers, QA folks, support people, program office people, release coordinators, business liaisons, time keepers, relationship managers … well, you get the picture: people with functions to perform on the project but no one to actually do the engineering work itself.  As an engineer getting assigned to the project, you run the risk of getting all the “real work” dumped on you.  If you can handle all the work, great, if you can’t, there will be fifteen people with charts and graphs and emails and ten other ways to make it obvious that you dropped the ball.  In subsequent sections, I’ll over tips on how to navigate in this type of project.

Too many Indians

A project full of engineers, developers, architects and coders sounds like utopia with a whole bunch of people all doing actual work.  A bunch of people that think it is great when some new, hot off the Internet coding technique can be used to make some function perform some task at wire speed with four lines of code.  All those people cost money and consume time. People, managers, which are responsible for tracking and managing money and time don’t have an infinite amount.  At some point in time, someone, somewhere in the company is going to ask the dreaded question: “Hey, it has been four months, how close are we to implementing that new FlimFlam product?”  This is the holy crap moment for the managers that are responsible for the resources on the project.  If someone is asking that question, it means the project is in a heap of trouble.  Since that someone doesn’t already know how far along the project is, how much it is costing, how on track the project is to cost as much as originally estimated and exactly when it is going to finish, the project has failed and nothing has even been released yet.  Managers will be swooping in to ask the dreaded questions:

“What have we built?”

“How long have we been building?”

“When are we going to be done building?”

“When can this be implemented?”

If you have a bunch of engineers sitting around trying to answer those questions, the answers are not going to be what managers are expecting to hear.  More than likely, all kinds of cool stuff has been half built with no plan to pull it all together and meet the original goal of the project.  Managers are thus put in the tight spot and will react with decisions on what to do next which you are definitely not going to like.

In the next part of the series I’ll cover how to survive with too many chiefs or too many indians.

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as an engineer that has a role to play on an IT project.

Boss: “Bob, looks like the FlimFlam Upgrade project needs a resource from our team and based on our team’s workload, I am going to give them your name.”

Bob:  <forcing a look of enthusiam> “Thanks boss, I’ll get right on it.”

If you already have some knowledge of this project from watercooler discussions or some other means and you see this as a positive assignment, you should take this opportunity to offer some sincere appreciation for the assignment.

Bob: “Boss, I apprecaite the opportunity to work on this project”

Something brief, to the point and low on the proverbial sap works just fine.  Now, if you view this as a negative assignment, I would still strongly encourage you to still offer sincere appreciation for you can’t be working on the cool projects all the time.  Making the best of the assignment will put you in a positive light in your bosses mind and can only increase your chances of being assigned something more postive next time.

If you are 100% clear on your role on this project, you are all set.  If you are unclear, don’t let your boss leave without getting that clarity:

Bob: “Boss, I just want to confirm, I am only fulfilling the project implementation into the test environment role on this project, correct?”

Believe me, your boss probably has ten things on his or her mind at the moment and probably doesn’t realize that you can’t read his or her mind as to what being a resource on the FlimFlam Upgrade project means.  You will cause more problems for your boss and then yourself if you go off and assume you are the test environment implementation person when in fact, you are only supposed to review the design of the system before it is moved into then testing phase.

Making sure you know exactly what role you fill on this particular project is critical.  Everyone on the project will most likely either assume your role is X or want your role to be Y and if you job aboard without knowing exactly what you boss expects, you will most likely fail to meet his or her expectations.

Projects where everyone knows their role and goals of the project are rare.  More than likely, the project you are about to join is top heavy in one of two ways.  The first is too many chiefs and not enough indians.  Like the proverbial saying implies, plenty of people taking about the work, defining the work, breaking the work into chunks or phases or milestones or whatever is great, but if there is no one around to actually do the work, you as an engineer or as a do-er is likely to get dumped on.  The second is too many indians and not enough chiefs.  Equally dangerous because the lure of a bunch of engineers doing cool engineering stuff without chiefs provide direction, priority and governance, time and costs are ripe of getting out of control.  The next part of the series will cover each in more detail with tips on how to avoid the pitfalls.