Off-Shore Development - Plan it right or Fail!

Off-shore development continues to be a discussion point within many organizations.  I've managed teams across the US and had the occasion where I've used off-shore resources.  Let me share some of the experiences in the hopes that it helps others that struggle with the model or are questioning whether to proceed with the use of off-shore resources.  I won't claim this represents the model to run off-shore development, ultimately, you need to make the decisions that will work within your organization.  Hopefully, this will shine a different light on the topic and allow you to gain insight that may help you make the decision to use off-shore development resources or to keep the development on-shore.

First, it is not easy.  If you think this will solve issues within your current development lifecycle - don't bet on it.  If you're going to seriously begin to use off-shore resources, you better plan appropriately, or you'll pay the price with development timelines that get extended and budgets that creep beyond your expectations.  In the worst case scenario, you'll end up rolling product into production that has not been properly tested and vetted.

Some of the breakdowns that my teams encountered in using off-shore resources are as follows:

1. Communication - eliminating the natural lag in communications as teams work shifts that do not align.
2. Design Aberrations - ensuring the product developed fully conforms to the original design/requirements.
3. Coding Standards - putting processes in place to ensure that the off-shore development team followed the development coding standards of our internal teams.
4. Quality of Code - ensuring that the code had been properly tested all the way through integration testing with other application silos/subsystems.
5. Quality of the Team - ensuring the consistency of development resources applied to projects.
6. Product Knowledge - ensuring that knowledge of team was retained from project to project.

The above list covers the major challenges that we encountered.  Let me go in to some level of detail so that you can get the flavor of what was experienced and how we handled the longer term needs of the organizations use of off-shore resources.

Communication: Each and every day, without your knowledge dozens and dozens of project decisions are made as developers lean across the walls and talk to each other or see each other walking around the office.  My teams have been no different, requirements and designs could change based on a hurdle that needed to be solved and a quick conversation in the hall.  Suddenly you have a team separated by multiple time zones - in my case, they had left the office for the day by the time we arrived in the office.  If the remote team had a question, or hit a roadblock and needed direction, there was an automatic lag of at least 1 work day.  If it was a serious issue, the team might loose several days as communication threads worked their way through email.  In extreme instances, we might have some of the remote team stay late or some of the local team come in early to establish conference calls and work out the issues.

Design Aberrations: The standard methodology we used to develop project requirements within the organization wasn't sufficient to support the use of outside resources.  Didn't matter if those resources were on-shore or off-shore, our teams were comfortable dealing with each other and could abbreviate how the requirements were documented.  There were a lot of things assumed within the requirements that didn't need further explanation because the teams had years of experience working together.  This continued to feed through the process as design documents were generated by the team.  Suddenly we introduced a team of developers that did not have that tribal knowledge.  The results were obvious in hindsight, the off-shore resources built the product to match the documented requirements and designs.  The only problem - those requirements and design documents didn't contain the unspoken elements known by the internal teams.

Coding Standards: Some of the products that we chose to develop off-shore ended up needing to be supported by local teams.  We quickly found out that the coding standards we had in place were not documented thoroughly and left many items up for consideration.  Translation, the remote team was producing code that looked like none of the other code that was used internally.

Quality of Code: The internal teams had many years of experience working together, touching each others code and making the necessary revisions to the code base.  Suddenly we had bugs that had been solved being reintroduced into the code base later in the development cycle.  Worse yet, we would find chunks of code that were never being executed, yet were loading up the code base.

Quality of the Team: Just as we were getting used to working with one set of developers, suddenly they would be reassigned to a different project and we would end up having to reacquaint ourselves with a new team.  To say that this slowed down development and introduced inconsistencies into the code base would be an understatement.

Product Knowledge: As we completed development with one project and started up the next project, we were not assured that the team we had gotten used to would continue on and do development on the next project.

None of this is serious and can be resolved, but you need to think through the engagement up front and take the necessary measures to protect your organization.  Here are some of the tactics we began to utilize to minimize the risk in the use of off-shore development resources:

Communication: We required the off-shore company to place one of their resources on-site with our local teams.  They became the primary communication point between our teams and the off-shore resources.  They sat in on the meetings locally and could catch the small things that needed to be communicated to the off-shore team.  They could do the impromptu meetings in the hallway and get that information promptly to the remote teams.  Our project timelines included buffers to accommodate the communication lag between the teams.

Design Aberrations: We ended up beefing up our Business Analyst and Architecture teams to create more thorough documentation.  Our documentation became much more thorough and attempted to accommodate the things that people took for granted.  The architectural diagrams became much  more sophisticated outlining all servers touched, all databases touched and were color coded to identify new, changed or removed elements.  Design documentation began to reference not only the objects that would be touched, but could go down to the individual methods and parameters when needed.

Coding Standards: We ended up going through our coding standards and documenting much more thoroughly how code was to be structured, how variables names were to be created, what security precautions were to be taken when creating the code, etc. 

Quality of the Code: Code created by off-shore resources was required to go through the same code review process that we used for internal teams.  This ensured that our senior developers were reviewing the code - exactly as would be done for internally written code and that they could catch issues and feed them back to the remote team.

Quality of the Team: After some experience with team members shifting, we ended up negotiating with the off-shore company to ensure that we had a core set of developers that would not be reassigned off of the project.  This allowed us to maintain some level of consistency within the off-shore team and addressed quality of code, coding standards and communication issues.

Product Knowledge: Similar to the Quality of the Team issue - by keeping a core team of developers assigned to our projects, the off-shore teams knowledge base of our products began to increase and they could begin to anticipate some of the issues ahead of time.

I want to state again, these were experiences that my team had in working with off-shore resources.  Other organizations may have different experiences.  Hopefully, some of these issues and the ways in which we resolved them will assist you with determining whether you can support the use of off-shore development resources.

I typically do not use off-shore resources unless there is a need to temporarily augment our internal resources to accomplish specific development/project goals.  That's a choice that I feel comfortable with based on the particular business needs within the organization.  In previous roles, I've had the opportunity to work extensively with off-shore resources.  If you're going to use off-shore resources, I highly recommend you pick a couple of small projects and trial a couple of different vendors to establish which one will work better with your current development paradigm.  Don't be afraid to switch  vendors if you don't feel you're being taken care of - ultimately, it's you that will be held accountable for the delivered product.

If you'd like more information on my background: LinkedIn Profile

Test Driven Development - Think about it!

Over the last few years I've been moving my teams towards Test Driven Development.  If you're not there, you need to be looking at this paradigm.  In essence, the following is what you are shooting for:

1. Write your test.
2. Run your test - the test should fail because the code hasn't been written yet.
3. Create the bare minimum of code that will allow the test to pass.
4. Continue to refactor the code until you are satisfied - is it simple, have you removed any duplication?
5. Repeat - accumulating additional tests until full functionality matches the agreed upon requirements and design criteria.

I've been on this push for a couple of different reasons: 1) The QA Team is spending an inordinate amount of time performing regression tests that should be in the build process; 2) The QA Teams and Development Teams should spend most of their time on new feature/new function testing - not regression testing; 3)  Within the old paradigm that we were following, by the time the development team member became aware of a defect in the code, they had long since moved on to other parts of the code and it was not fresh on the mind.

I've recently spoken with several groups of students - some high school and some at the collegiate level - and the one common theme that I have been impressing on all of these groups is that they need to think about testing first.  That means while doing the design work and prior to any code being written, they should understand how they will test the code and then execute against the plan.

In a separate session. when meeting with some of the instructors - another individual recommended that the instructors should have a base set of tests created that the students will need to execute against their assignments.  The students could do this at any time to get immediate feedback.  If an instructor were to pursue this paradigm within their classrooms, I would encourage them to create a portion of the tests, but force the students to create their own set of tests.

Unless our teams are working on a completely new system - there should exist somewhere in the organization a base set of tests that cover the current functionality.  It may not be extensive, but it's there somewhere.  That's the baseline!  No build of the system should happen without improvements to that baseline with your development team increasing the code coverage with additional unit tests that are then included in the set of regression tests the next time that code is touched.

Let's face it, immediately after the code has been written and the developers focus shifts on to the next task, their ability to maintain the code begins to drift.  I'm not saying they can't maintain it, but that they will need to spend time re familiarizing themselves with the code and then planning how to make the change.  Additionally, you can't guarantee that the next time the code needs to be touched it will be touched by the same developer.  By having these tests complete and in the pool of regression tests, you set an expectation with the developer that they can't claim they are complete with the code until all regression tests are complete and they can prove that they have tested against the new feature/functionality of the application.

Really, when it comes down to it, it's about accountability within the development team.  They are just as responsible for the quality of the code as are the people working the front end of the project - discovery and requirements, design - and those working the back end of the project quality assurance and the user representatives.

If you'd like more information on my background: LinkedIn Profile

STEM - Stop Talking, Start Helping!

There is a lot of talk across the nation in promoting STEM careers with our younger students.  This continues to be an issue that we need to address.  More jobs continue to open up within these fields and that trend will only accelerate as the Baby Boomers retire.

Take a quick look at the number of job openings that are expected thru 2022: BLS: Occupational Outlook Quarterly.  Let's review the top jobs identified in this report (as of Spring 2014):

• Software Developers - 218,500 openings thru 2022, average wage $92,660
• Computer Systems Analysts - 209,600 openings thru 2022, average wage $81,190
• Computer User Support Specialist - 196,900 openings thru 2022, average wage $46,620
• Software Developers, System Software - 134,700 openings thru 2022, average wage $101,410
• Civil Engineers - 120,100 openings thru 2022, average wage $80,770

You know what, those are pretty good wages!  I recognize that these are not the starting wages, that said, you can see that overall, these are jobs that will be in demand.  Students entering into these jobs should see wage increases that will allow them to earn a decent living.

My focus in this post will be careers in Computer Science.  While other STEM careers are critical - I'll focus on those that I'm most familiar with, those that have powered my careeer.

Unfortunately, here in the States, we are doing a very poor job of educating our students about what opportunities are available and are not focusing our curriculum to encourage young students to explore the career choices.

Only 1 in 10 of our high schools offer computer science programs for their students (as identified by TEALS).  That is a scary statistic - if 9 out of 10 schools can not provide early experiences to students that might be interested in Computer Science, how are we expecting these students to make the choice to pursue degrees in Computer Science.  More importantly, if it is this bad at the high school level - what do you think it looks like at the middle school level.

I firmly believe that if we don't find a way that allows middle school students a way to explore these careers early and then do not reinforce that through high school experiences, that we are failing the next generation.  More importantly, we are putting the future of our companies at risk.

So, here are my ideas of what needs to be done:

• Our local school boards need to find a way to introduce computer science curriculum into all middle schools.  These courses need to count as math or science credits.
• We need to specifically find ways to encourage both young men and women to take these courses.
• Our local school boards need to find a way to introduce computer science curriculum into all high schools.  These courses need to count as math or science credits.
• Alternately, some states are declaring that computer language courses would count as foreign language credits.
• Our states need to fund the expansion of STEM exploratory courses at both the middle and high school levels.
• Businesses need to step up and provide volunteers to go into the schools and assist students as they explore STEM careers.  Some of this is being done through initiatives like Lego League, but we need to find these types of programs and make them available to every school, every year.
• Businesses need to open up and hire more entry level technology students.  I have seen the tide shift to where many companies now only want to hire people with several years of experience.  They no longer want to hire newly graduated students and mentor them into the next generation of experts within their company.  Or they only want to contract and rotate people in and out every 18 months.  That may work for their bottom line today, but it destroys the expertise that they will need when current subject matter experts retire.

And, yes, before you ask, I'm holding myself accountable.  For years, I have taken time to regularly talk to high school and college students about career opportunities and what life is like working within the Computer Science field - specifically software engineering.  I have volunteered to assist as schools present various tech initiatives for their students.

If those of us in this field don't take the time to encourage the next generation to step up and become the future technology experts, who will?  If we don't take the time to encourage our schools to address the educational needs that will drive job opportunities, who will?  If we don't take the time to personally lobby/communicate with our state leaders on the need to drive change in this area, who will?

If you'd like more information on my background: LinkedIn Profile

It's NOT all about you, it's about the Team!

I'm not a success without the people on my team!  Flat and simple - if they aren't succeeding, then I'm failing.  As a leader inside the organization, it's one of my responsibilities to look out for the needs of my team and find ways to make them successful.  I can't guarantee them success every time, but I need to find ways for them to succeed more than they fail and within their failure, I need to recognize that I own some of that failure.

I've seen people that have been great contributors on the team suddenly put themselves in a position where they look like they are going to hit the wall.  I've had to step in-front of them and prevent the smash up that is about to occur.  Sometimes these discussions can be difficult, because they don't want to admit that they are about to fail.  Sometimes there is a look of pure relief on their face when someone steps in and says - hey, I'm here to help.

One of the first projects I worked on after becoming a manager was a fairly mundane project needed within the organization - there were several pieces of the software being developed and one of the pieces was being held up because there was nobody else to work the issue.  I made the decision that I would jump in and work the issue myself.  At this point, my boss asked me why I was working on the code.  I explained to him my logic and he began to ask questions:

• If  you're working on the code - who's going to keep track of all the pieces that are moving within this effort and make sure overall we're on target?
• If you're working on the code - who are your engineers going to escalate the issue to when there's a problem and how will you manage those issues?
• If you're working on the code - who's going to keep myself and the rest of that management team aware of the status, issues, risks and plans?

There were several other questions - but you get the general sense of the conversation,  I was young and eager and for every question he had, I had an answer, me!  My manager made it clear to me that this was not the right answer and that I was going to end up hitting the wall.  I assured him, that I would be able to handle all of it and went on my merry way.

Soon, I began to trip up on myself - at first it was missing a status report here and there, not escalating an issue that needed to be escalated.  Then the impacts grew - I wasn't paying attention to all of the different moving parts and coordinating the delivery.  I hit the wall.  My boss looked me in the eye and asked me what I was going to do to clean it up.  I had failed!  Luckily, he reached out and helped clean up the mess and get the project back on track.  But what he taught me happened after all the pieces had been put back together and the project was again running forward.  He sat me down, told me that this time he had allowed me to fail and had helped me out so that I could learn what not to do going forward!  The next time this happened, if I let it happen, I would need to clean up the mess by myself.

Where to start?  First I learned as a manager, it's tough to be the one in the details and still be the one coordinating everything else that needs to be done.  Two, I learned that sometimes it's alright to let people fail.  Three, I learned that when somebody does fail, you have to be there to pick them up and help them get back on track - give them the ability to learn.

Now in some instances - the failures begin to outweigh the successes and you come to the moment of truth.  Is there a way that I can make this person successful, or have they proven that they are incapable of performing within the role that they've been hired for - a difficult decision.

As leaders - either formal supervisors/managers or informal project managers - it's not enough just to do the tactical parts of the job.  It's essential that we work work with the people we touch in the organization and help lift them up.  Only if we truly give them the tools and skills they need to perform their role and prepare them for more difficult responsibilities in their future, will we reap the rewards and succeed within our own role.

If you'd like more information on my background: LinkedIn Profile

Dysfunction within the Team - Breaking down the barriers!

Sometimes I'm left surprised when an issue hits my desk and I begin to work backwards to find out what happened.  In too many instances, I can trace it back to follow-through.  Someone in the organization knew something, or was assigned to do something and for some reason forgot.  What's even more irritating is when I'm the guilty party!

Recently, I was rightfully called out by one of my peers for not communicating a decision impacting a critical project out through the organization.  She had every right to call me out on the lack of communication.  It was my error and I could do nothing but agree with her and acknowledge the failure.  I like to pride myself on the fact that have strong communication skills and working relationships with my peers, and so I take this one personally.  There are many excuses that I could use - I'm too busy as we move several key projects into production ahead of our year end production freeze; the Project Manager should have communicated that out to the team.  Ultimately, I made the decision and I had the responsibility to communicate the decision across the organization - especially when that decision was going to put pressure on other teams across the organization.

This is not unique to myself.  As I began to explore at the beginning of this post, too often I look at the root cause of an issue and it all goes back to someone knew and didn't think to share that knowledge.

I recognize that some of this is human nature.  In the heat of the moment, decisions will be made that we believe will move the process forward and get the entire organization closer to the end goal.  While that may be the case - follow-up is critical.  Let's face it, we've all sat on the receiving end of some decision that made our lives miserable.  We've had to deal with the fallout when that information comes at the last minute.  I will be the first one to step up and call someone out when they do that to myself or one of my teams - it's only fair that I take the feedback when I'm the one causing the problem.

To allow this type of honest feedback - you need to be willing to trust the teams you work with on a daily basis:

1. Your direct reports
2. Your peers within your supervisors team
3. Your peers across the organization with whom you deal with on a daily basis

One of the best books that I've read on this topic was written by Patrick Lencioni, "The Five Dysfunctions of a Team".

This book leads you through a scenario of how a group of individuals that didn't work or trust each other was transformed into a highly functional team.

I was first introduced to this book, by my current boss - our CIO.  It was the first thing that he wanted me to read after I was hired.  In fact, he sent it to me before I even officially started.  It is now one of my favorite books.  I in turn have required all of my direct reports to read the book.  I encourage my team to be honest with each other and to hold each other accountable in their daily interactions.

We have been hired for a purpose.  We are here to make a difference, to move the ball forward.  That means holding ourselves and others accountable for the deliverables that people throughout the organization rely on so that they can do their job.  We must open ourselves up to others, understand the story that is driving their actions and be prepared to receive open and honest feedback when we fail to live up to our commitments.

Don't get me wrong - this isn't a directive for you to walk around the building pointing fingers at people and telling them they're not doing the job - chances are if you did you'd have a line of people at your desk telling you that you didn't do your job.  What you should do is be willing to engage in a positive open communication.  Explain what you are seeing - you may not have a full understanding of the situation and be prepared to change the direction of the conversation based on what you hear.  If the person truly is responsible for failing to deliver, than it's up to you to find a positive way to work with the person and manage the situation.  Help them help you!

If you'd like more information on my background: LinkedIn Profile

Leadership - Getting Beyond Management!

Are you managing or are you leading?  The two are very different and if you're not leading, you shouldn't be a manager!

Managing is handling the tactical day to day activity within a group of people.  Ensuring that milestones are hit, coordinating activity between your team and other teams, reporting progress, etc.  In short the manager maintains the status quo - acting within the defined processes to keep the business moving.  They manager accomplishes activity due to their authority.

Leading means changing the dynamics to get the best from the processes and people.  A leader inspires the people around them to effect change.  They can establish a vision and know how to tap into individual team members to get them to see the vision and how they can contribute to the overall vision.  Leaders instinctively know what motivates an individual within the team and can appeal to that individual to use their strengths to close the gap between today and where the leader wants to be tomorrow.  Leaders are focused on the longer term vision.

I freely admit that there are moments in time where I must manage - stepping out of my normal role and acting in a more tactical fashion to help the team push something across the finish line.  This isn't a bad thing, and to be quite honest I think as a leader sometimes you need to do this to ensure that you understand what is really happening within your teams.  I also, sometimes by choice, make the decision to drop into meetings I normally would not attend - project status meetings, implementations, integration test sessions.  Not only do I get the benefit of getting to know some of the team members I would otherwise not interact with on a regular basis, but it also gives me a temperature of what is really happening within various projects.

However, my daily focus is, and should be, at a different level within the organization.  My job is to look ahead of the teams and remove roadblocks.  Understand processes that are not working and change those processes.  Identify when changes in the business may require organizational changes within the teams that I manage.  Identify opportunities within the industry and find ways to get ahead of our competitors.  Find ways in which we can change that will improve the experience of our customers.  Working with our Human Resources team to build pipelines to talent pools so that we can fill vacancies or know where we need to go to find resources when we expand our teams.  It's also my responsibility to look beyond the tactical needs of the organization and create the vision for my part of the organization.  Where do we need to be and what and how do I change things to get us there - then driving that vision down and through my organization.

When I first moved into a management role -- I figured my job was to be the tactical expert.  Help my individual team members get stuff done.  Now as a Vice President, I still need to be in tune with my team members and help them get stuff done, but along the way, I've learned being a manager/leader is so much more.

I want my managers to be leaders within their teams and within the organization - no, they don't necessarily have the influence that I have to effect change, but they can lead and drive change within their teams and the processes they interact with/manage:

1. Managers are the closest link to individual Team Members.  They need to be driving the growth of each team member.  One of the mantras that I have within my teams is that you can't get promoted to the next level until your doing the job of the role you want.  In other words, if you want to move from a Software Engineer I to a Software Engineer II, you must demonstrate you can perform the duties of that new role.  It is the Managers job to establish a growth plan with the individual Team Member and guide them/mentor them so that they can see that promotion.  I ask each of the managers within my team to establish individual learning plans with each team member and constantly work those plans with the team member.
2. Managers see the reality of the process works versus the theoretical process that was defined.  I encourage each of my managers and direct reports to constantly provide feedback on what is working and what isn't and most importantly, if they think it is broken, how do we change the process to make it work better.  Even better, if they are working a project and want to try a new way of doing something, let's talk, give it a whirl and see if it gains us anything.
3. Managers are the actual touch points between their department and other departments, I expect them to drive the relationship and identify how to improve communications between not only the departments within my organization, but departments reporting up through my peers.  It is an expectation that they act as a role model to their team members in showing that we can establish positive working relationships between departments - that doesn't mean we always agree, but that we find a way to move the conversation forward in a professional and positive way.

This isn't meant to be an exhaustive tale of how I see my management team playing within their roles, more of a prime to get people to see that they can play more than a tactical role.
 
I once had one of my bosses tell me, "I don't know what it is you do, and quite frankly I don't have the time to figure it out.  When you need something, tell me who I need to talk to and what I need to say."  Was this the worst person I 've worked for, no.   Did I have any respect for this person, no.  While he had the title of Director, he didn't mange, nor did he lead his organization.  He came in in the morning and sat behind a closed door - rarely interacting with any of us.  Luckily, he was gone within 6 months - the company had seen fit to move him into a different role.  I left the organization shortly after that, but have never forgotten those words.

Are you being a leader for our teams?  Are you setting the table and letting people within your organization lead where they can?

If you'd like more information on my background: LinkedIn Profile

Estimates - The Buck Stops with You!

Why are people so uncomfortable making a decision?  I admit I scratch my head frequently at some of the issues that land on my plate because someone was uncomfortable making a decision – or because they feel they haven’t accumulated enough information.

This is not a phenomenon unique to my current organization.  I’ve seen it across most organizations that I’ve worked in.  Managers have engrained into people that they are not allowed to make decisions and that they must review everything prior to anything getting done.  YIKES!  And then we wonder why people fail!  Better yet, we wonder why people leave us and move on to a new job – leaving us to spread the workload around to others on the team.

Look, I won’t claim my teams are exempt from this pattern.  But I do try to encourage people to think through problems they are facing and if they are unsure of a direction, at least bring options into the conversation when we sit down to have a discussion.  This at least allows me to see that they have thought through the problem and are attempting to address the issue.  Usually through conversation they’ll come to some type of a conclusion, thank me for the discussion and head back out.

I think where we struggle the most within my current teams is getting people to make estimates on project activity.  This is a personal decision by team members measuring how much work they will be responsible for against requested project activity.  When we first introduced this concept, there was a lot of push-back.  And to be frank, there were a lot of errors in the initial estimates.  But over time, people have grown more confident and are estimates are aligning better with the actuals that we measure over the life of a given project.

We go through regular training with people that are new on our teams.  It really doesn’t matter if they’ve been in development or whether they are new to the ropes.  Most developers have never been trained on how to produce reliable estimates.

So how do you pull together an estimate – well, for one thing, it’s different depending on what stage of the project you’re in: 

1. Discovery Phase: Usually estimates at this stage are done by someone within the management chain along with senior level technology resources.  How?  Well, the truth of the matter is the project scope is looked at in comparison to other projects that have been completed that smell like or look like they have similar impacts.
2. Requirements Phase: Typically this is a minor refinement of the estimate that was given in the Discovery Phase.  Any changes to scope are accounted for and typically there are additional details highlighted that point to previously unconsidered impacts.
3. Technical Design Phase: Now we are putting some meat on the bone.  At this point, technical resources have engaged and identified impacts across current systems/application silos and have also identified where new functionality must be created.  Along with the technical estimates business teams have assessed impacts to current and new processes.  Between the two paths, the full project estimate is considerably more accurate than anything that was put together in the first 2 phases of the lifecycle.
4. Development Phase: Some organizations perform the final detail design in this phase.  If so, this is the last chance to update those estimates both from a technical and business perspective.  This should allow the resources that are going to do the actual work to review the technical designs, identify the specific chunks of code or the business processes that are going to change the final say in what amount of time is necessary to complete project activity.

Rules of the road when it comes to performing estimates:

1. If you’re implementing new technology into your current technology stack – maybe you also need to set aside time to install and integrate the technology.
2. Don’t forget process changes.  Sometimes these changes can be just as critical to the project timeline as the technology changes.  Don’t underestimate the impacts these can have across your teams.
3. Don’t forget testing – and I’m not just talking about QA.  I’m talking about Unit Testing, Integration Testing, Parallel Testing, Performance Testing, Regression Testing, New Feature/Function Testing, and UAT Testing.
4. Don’t forget implementation planning and actual implementation activity.  While the universe may have been created with a big bang – in most instances you are going to see implementation activity spread out over a period of time.  Some implementation activity begins before the code touches production, and some activity happens months after the code is in production – you need to account for all of the activity.
5. Don’t forget to provide a buffer for 3^rd party activity.  I have yet to see a 3^rd party engagement go off without some type of change that has to happen.  The initial timeline provided for the engagement never usually is achieved.

Items for consideration when building the estimates:

• How many screen modifications need to be made?
• How many new screens are there in the project?
• How many web services need to be modified?
• How many new web services are there in the project?
• How many reports/data extracts need to be modified?
• How many new reports/data extracts need to be created.
• How many tables/stored procedures need to be modified?
• How many new tables/stored procedures need to be created?
• How many 3^rd party apps need to be touched?
• How many new 3^rd party integration activities are needed?
• How many processes need to be modified?
• How many new processes need to be created?
• What infrastructure changes are needed – servers, server types, routers, switches, security devices?
• What new infrastructure pieces need to be installed – servers, routers, switches, security devices?

Realize that you’re first efforts are going to be wildly off base.  Don’t be afraid to tell your team that you’re giving them time to get better at creating estimates.  This means when they’re wrong – it’s a conversation not a point against them in their annual review.  Use each estimate as a coaching opportunity when the final numbers come in – what they did right and what didn’t look so good and how do we make it better.

This by no means covers it all, but points you in the right direction.  Now I’ve heard some people say that in an Agile process you don’t need to worry about this.  Yeah, right.  Trust me, someone in the organization is telling the CFO what this thing your building is going to cost – how many 2 week iterations it’s going to take to get full functionality.  If you’re not responsible for making those conversations happen today – you will be at some point.  Better to start figuring this out know, before you’re asked to provide that first estimate.

Realize that you’re first efforts are going to be wildly off base.  Don’t be afraid to tell your team that you’re giving them time to get better at creating estimates.  This means when they’re wrong – it’s a conversation not a point against them in their annual review.  Use each estimate as a coaching opportunity when the final numbers come in – what they did right and what didn’t look so good and how do we make it better.

If you'd like more information on my background: LinkedIn Profile