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

On-Boarding - Skip at your own peril!

Once you’ve place that offer out there and the candidate of your dreams has said yes, it’s time to make sure that you smooth their way on board.  You can either let it happen, or you can MAKE IT HAPPEN!

Through previous postings, you’ve probably divined that I’m all about process and on-boarding a new team member demands your attention.  This is the opportunity to show your new team member that you care about them and you want to ensure that they have a comfortable entry into the team.

Most people, no matter how experienced are going to feel some level of discomfort as they take on a new role.  There are new people, unfamiliar places, processes that they’ve become comfortable with will need to be thrown out, the path to get decisions made will change, and the politics of the new place are unknown.  This can make for a very uncomfortable period and can ultimately make the difference of the new team member staying with your organization or fleeing back to somewhere where they are comfortable.  I’ve seen it happen – someone comes in and a few months later is gone.  When you ask why, they say, ‘I just never felt like I fit in’.

First – make sure you’ve sold the job that exists!  If you want someone to run screaming from the building, hire them based on some fantasy version of the job and then stick them with reality.  Not only will you burn bridges with that person, but they’ll tell everyone they know what a horrible place your business is and how incompetent you are.

Next – once they’ve said yes, welcome them to the team.  Follow up the official call with another call a couple of days later, congratulate them on taking up the new role and let them know you’ve already begun planning their first few days in the office.  You can tell them that the team knows about their coming on board and that the team is excited and is looking forward to meeting them.

Now comes the real work – actually build an on-boarding plan for the individual.  This plan should include the following and cover the first couple of weeks:

1. Key contacts for this person and their contact information.
2. Time to tour the facilities and show them where they’ll be spending most of their time.
3. Introductions to fellow team members.
4. Introductions to key contacts.
5. Introduction to your boss.
6. Setup meetings for 1-on-1 time with key people they will work with.
7. Setup meetings for 1-on-1 time with yourself (their manager).
1. These should be daily – initially set for an hour so that you can bring them up to speed on the role that they’ll be playing, then as time goes on these meetings can be shorter, just a touch base to answer questions about people they are meeting, processes they are unfamiliar with, etc.
8. Setup time for training
1. HR training
2. Department training
3. Job specific training
9. Time to show them where they can find key information on your intranet
1. Team documentation
2. Team standards and processes
3. Company information you feel is important
4. Standard training material if available
10. Any other items that are critical to your environment and team

I’ve never been told by a team member that the on-boarding process was not welcome.  Early in my career, when working at other companies, I had been told that the lack of an on-boarding plan made the team member uncomfortable.  Well, lessons learned.  I hadn’t been shown then and didn’t know what a proper on-boarding plan was and what it could do for the new team member.  I took time to learn and over the years have been involved with companies that were good and companies that were bad at on-boarding new team members.  

When done right, I’ve even had employees compliment me on the on-boarding process.

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

I Can't Find The Right People - Yeah Right!

I've had several discussions lately with different groups of people about hiring people.  I'm somewhat surprised at the attitudes of some of the decisions being made or expressed in these discussions.  Here are some of the comments I've heard:

1. We'll only hire people that have x years of experience.
2. We'll only hire people that can prove they have experience using xyz framework.
3. We'll only hire people that have a Bachelors degree,
4. We'll only hire people that have a Masters degree.
5. We'll only hire people that are experts in programming multiple languages.
6. We can't afford to hire newbies, it's too distracting.
7. We need programmers who also have experience as system admins?

Maybe we don't have a shortage of qualified applicants; maybe we're being too picky!  You want 7 years of experience, but you won't consider an applicant with 5 or 6 years of experience, really?  Someone can demonstrate that they know how to code and can discuss in detail their contributions to sophisticated development efforts – yet they don’t have a degree and you won’t hire them?  Your organization uses some hot off the press framework, or some framework that isn’t used by 90% of the developers breathing – yet you won’t hire a skilled programmer that has a track record of learning new languages frameworks and give them a few months to come up to speed?  You find a candidate that can develop is several languages – but is missing a key scripting language that your company uses, and you think that passing up this individual because you can’t afford to give them a little time to learn the scripting language – and this is a good idea?  You don’t want to hire new developers right out of college because you can’t afford to distract your staff – meantime, they’re working 70 hrs a week because nobody is there to handle the simple stuff or address the tickets being opened because of errors in the production environment, great choice!

As hiring managers, we’re supposed to be taking into consideration the long term needs and health of our teams.  I find these statements be short sighted at best.  Hiring inexperienced programmers into the organization provides several benefits that we need to be aware of and fight for:

1. They can take over the lower level complexity tasks that do nothing more than distract the more highly paid resources.
2. They can handle production problems that act as a distraction to the entire team.
• Side benefit – this forces these younger developers to learn the ins and outs of the systems that they are supporting so that they can transition into the development team at some point and take on more complex development tasks.

Part of the problem is we are relying on automated applicant tracking systems that filter out everything but an exact match with all of the keywords/buzzwords that we created for the job description.  These systems don’t allow us to find those gems that we can bring into the organization and grow into the next superstar.

How many times have you gone out and hired some superstar, just to have them leave 2 years later?  Sometimes these folks keep moving around because they know they can keep getting a bump in salary.

The real key is to understand the qualities of the people that currently work in your environment.  What makes them stay?  What makes them successful?  You then need to really hone your job descriptions to describe the type of people you want in the organization.  Then you need to adjust the applicant tracking system.  Stop filtering candidates out on skills and find ways to identify candidates based on the real traits you need in the organization.

If you’re a small company – do you really want to hire someone that has a track record of only working in large organizations and has a history of job hopping?  If you need developers that need to be able to meet with non-technical users – shouldn’t you be looking for a developer that has a track record showing that?

I’ll go further – sometimes you need to forget about finding someone with 5 years of experience and focus on finding an entry level programmer that displays a passion for learning, knows how to communicate, has local connections and will become the next rock star in your organization. 

Look at one point, none of us had experience.  Remember how excited we were when we got our first job?  Remember how we tore into any available documentation to learn?  Remember what we felt like when we moved our first code into production?  Someone, at some point, reached down, put their hand out and gave you a chance.  Now it’s your turn!


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