Archive for October, 2010

Jumping to Solution

Have you ever driven your car into the mechanic’s garage and said “The fuel pump is bad.  Can you please change it?”  While this is a direct method, I wonder what happens when it’s actually a problem with the water pump.
When we start gathering requirements and allow our stakeholders to jump to solution, we should not be surprised when we end up with a fuel pump instead of a water pump.
It is easy to see how this happens.  Many of our stakeholders are knowledgeable about our existing systems.  They may also be well-educated on solutions that exist in the market place.  And with the best of intentions, whether to speed up delivery or reduce time spent on analysis, they come prepared with mock-ups, software brochures, or even code (everyone can code in html, right).
The conflict that this causes is that it boxes you (the Business Analyst) into a corner.  IT solutions are a lot like art – it should be a creative process.  If you are restricted from the start of the project with a shape or a technique, it influences your enthusiasm for the project and definitely the final result.  For example, your Customer Service Manager arrives on day one of a new project and announces that the order entry process for your company’s new product must be built within the existing system.  No exceptions and his boss agrees.  No consideration as to what it will cost to build-out the hardware to support the additional volume of orders or customer service reps.  Not willing to talk about a new system that might cost half as much to develop as compared to the cost of changing the existing system required to support sales of the new product.
The other consequence of jumping to solution is the amount of re-work that is at risk if you find out the solution set from the start is not right.  This is a significant risk.  Heaven forbid that you have already set a budget and schedule around the proposed solution as it will not be a fun conversation with your project sponsor when they find out that you have to go back to the requirements phase because of your immediate jump to a solution.
My final concern with jumping to solution is that people tend to lose sight of their objective(s).  This is concern rings true with an IT project that is delivering a solution as much as a process improvement effort.  If you allow your stakeholders to get carried away with an initial focus on a solution, the scope is in jeopardy.  You and your team have been asked to build a process within your organization to facilitate the receipt of IT requests.  On Day 1, someone on the team comes to the table with a solution – great new software that a vendor they know supports at a low-cost.  Everyone is excited as they have a million other things to get done – and this effort just got checked off their list.  Time to cheer?  Maybe.  Not likely.  Does the software support the number of users you will have?  Does it provide a way for a requestor to track their request?  Does it provide a way for IT to support the 24 hour response SLA that your boss has committed to? Without documenting your requirements, how do even start to evaluate a solution?
So what do you, the Business Analyst, do?
First, tell them thank you.  Acknowledge their effort as they are doing what they perceive is needed to help get the project off to a good start.  And their contribution gave you “somewhere to start”.  “Somewhere to start” is your signature statement in this situation.  You are giving them credit for their effort but also noting that the effort is started not done.
Second, bring them back to the requirements.  As you have surely been planning to start this project for a while, you likely have an outline of business processes potentially impacted by launching this new product.  Pull out your list and start talking your stakeholders through it.  Occasionally, you can ask “thinking about your proposal, how would this work?”  You may find that the proposed solution would work great or it may not.  Either way, it’s a win as you are demonstrating support for your stakeholder’s hard work and learning about how a potential solution may or may not meet their needs.
While the enthusiasm that your stakeholders are demonstrating by bringing a solution to the project is fantastic, it comes with risk and could result in a significant price to pay in missed expectations, increased budget, and delays in your schedule.  With risks that high, it may not be wise to allow your project team to go in this direction.

October 28, 2010 at 9:00 pm Leave a comment

Adjusting to a New Job

I recently started a new job. Fun, exciting, challenging – oh yes! It is the first time I have changed companies in my career so I expected a significant adjustment. I also knew that as a new person at the company in a management role, I would need to prove my worth quickly. Hopefully some of my tips can help others, so I thought I would share them here.

When I first prompted to a manager role, my director at the time met with me on my first day. First, she offered me congratulations on my promotion. Then she knocked me back into reality. She said that anyone in a new role should expect the following:

  • First 30 days – gain an understanding of your role and how it fits into the organization
  • First 60 days – SWOT analysis on your team (if in a management role), know how your organization fits into the company, and know the processes/systems involving your team’s role
  • First 90 days – Make a difference – you should have made a noticeable difference in some area of your team

No pressure, huh? She set a high bar but I realize now that this set of rules helped me to find a repeatable way of starting into a new position. Each of us plays a role in our organization. We receive input from someone. We do work of some sort – we “make” something. We provide that output to someone else. We may have internal or external customers. We may work with internal groups or outside suppliers for those inputs or outputs. Your work may be very repeatable (due every day, week, month, etc). It could vary – depending on a trigger.

The very first thing you should do is plot your course. Divide up your responsibilities (inputs, processes, outputs/suppliers & customers, deliverables by timeframe). I built a brain-mapping document that reminds me of these different areas. I also include some organizational aspects.
My Team –
Roles, Years of Experience, Career Goals, Open Positions, Software/Hardware Used

My Organization –
Goals, Partnering Organizations, Internal clients (other business units)

Environment (IT focused) –
Software, Hardware, 3rd Party Software, Connectivity

Starting a new job is overwhelming enough but I have found that having a logical map of what I need to learn helps me to stay aligned to the 30-60-90 goals.

Another suggestion for adjusting to a new job is to know your own strengths. It is hard to go into a new position and not know much. So leaning on things you do know can bring you confidence. If you have strong communication skills, leverage those in your activities. If you are good at analysis, then use those skills to dig into your new position.

Finally, my suggestion would be to make new friends. In an organization where people enjoy their jobs (yes, they do exist), people will love talking about what they do. Find these people! Set up time to learn about their positions, what they like, what they don’t like, what works well, what doesn’t. And as you talk to more and more people, you will start seeing how these positions connect. You will notice trends. You will find a pattern for recurring issues that plague multiple teams. These are some of your areas of opportunity to make a difference! The other bonus is the relationships you will make through these conversations.

Starting a new position is thrilling and challenging. You can set yourself up for success by setting goals for your first 30, 60, and 90 days, analyzing your situation, and build relationships and knowledge through interviews.

October 25, 2010 at 7:46 pm Leave a comment

Team Development – It Takes a Village

I recently heard a someone in a leadership position state that if someone in their organization was less than willing to help others on the team learn and were fairly close to retirement, that the person should just be left to their own tasks.  Really?  Is the amount of effort it would require to force that person to be a more active team member be worth it?  Would my attention as a leader have a better return on investment if I focused on something else?  I understand the logic but I have strong issues with the idea of letting it slide.  Team Development – using the talents of all team members – is an obligation of any manager, and it should involve all team members.

Each employee is at a different point in their employment life cycle.  Some are shiny and new – eager to learn and in need of guidance.  Others are experienced in their position and established as a professional.  And some are nearing the end of their professional career – years of experience, strong domain knowledge, and thoughts lingering on what is next in their lives.  Regardless of whether a team member is 5 years into their career, or 5 years away from retirement, they should all play an active role on a team.  The more experienced members of your team have an important role to help grow the knowledge of the next generation.  While some may see it as an extra task on their already full plate, they should see it as an opportunity to leave their mark – a legacy of sorts.  Here are some suggestions on how to keep your team focused on development throughout all team members:

1.  Mentoring – As you have new employees join your organization, they should be assigned 2 mentors.  The first one should be someone within their organization who is an expert in the domain the new resource will be focused on.  The mentor should develop a plan for what to share with the new employee.  The workload on the mentor’s to-do list should be delegated, in part, to the new employee.  Simple tasks that will re-enforce their learnings can help the new employee develop.  The second mentoring relationship should be one between the new employee and someone in a leadership in the organization to help the resource learn more about the “big picture” within the organization (strategies, objectives, roadmaps, etc).

2.  Peer Reviews – If your organization does not already have a Peer Review process in place, this is a great opportunity to distribute knowledge and spark interaction between team members!  Newer employees get a chance to learn from the experiences and work style of more experienced employees.  More experienced employees have an opportunity to share their knowledge and perhaps, learn something new along the way!

3.  Leadership Role – Seize the benefit of having more experienced team members on your team and delegate some of your management responsibilities to the team member(s).  Let them take the driver’s seat on a few projects.  This gives them something new to keep them challenged and engaged, and gives them a chance to step in as a leader to demonstrate skills & knowledge to others on the team.

There are some resources, both new and experienced, who may push back.  Some newer team members may push to learn on their own – wanting to do things their way.  Besides screening for this type of person during the interview process (future blog post….), you should immediately offer this person some feedback.  While they likely bring some talents to the position, they would be even more successful if they took the opportunity to learn from more experienced team members.

Employees nearing the end of their professional life cycle may resist as well.  They may push back on the idea of taking on new responsibilities.  While you can implore to their desire to help others, lead, or to teach, you may have to resort to more of a “parenting” technique.  I remind my 6-year-old often that being a big brother has its pros & cons.  On one hand, he gets to do things first.  On the other hand, he has an obligation to set a good example.  Same thing goes for your team members.  Each team member, including the manager, is setting an example for others on the team.  And each team member owes it to each other and the team as a whole, to support each other.  That means pitching in on big tasks, celebrating accomplishments, offering constructive feedback and teaching.  If your team member cannot get on-board with this, then you may need to discuss their role on the team and your expectations.  This may not be a fun conversation, but it’s a necessary one.  An investment was made into this employee through experience and training.  The investment was not only for them to be able to accomplish the tasks assigned during their career but also to pay it forward and help develop others within the team.

As a leader in an organization, it is your responsibility to develop your team members.  While it may require you to spend some time and energy, it will be rewarding for every member of your team.  With consideration to the experience and knowledge within each of your team members, and some guidance, you can leverage each team member’s talents to help strength your team and their ability to succeed together.

October 19, 2010 at 8:18 pm 2 comments

Recognition Well-done

Recognition is an important part of any organizational culture.  Everyone deserves to hear how their contribution made a difference.  Here are a few suggestions to help further develop your methods for recognition.

1.  What Floats Their Boat – each manager owes it to the people who are part of their team to know how each person likes to be recognized.  Some people enjoy public recognition – a “Job Well Done” in front of your team or client.  To someone else, a public display humiliate them but a hand-written thank you note may mean the world to them.  Some people love a pan of brownies, others may enough being told to leave 30 minutes early one day.  Know what motivates your team, and you will see their faces light up.

2.  Thanks is Not Enough – Thank You are powerful words but they are not enough.  When someone goes above & beyond with an effort, it’s usually for many reasons but a powerful one is to make a difference.  Besides the paycheck, a strong motivator for having a job is to feel like you are contributing to society.  With this in mind, help your team members realize how their efforts are contributing to making things better.  And please, do not just tell them about how they are “helping the company”.  Be specific – tell them how their effort made a difference to a Customer, a group of Employees, or Shareholders.  Not only will they feel rewarded for their effort but they’ll also have a better idea of how they fit into the big picture, which helps to increase Employee Engagement.

3.  Peer To Peer – Recognition isn’t just about telling people who work for you that they’ve done a great job.  Everybody likes to feel good about their contributions.  Take the time to thank others that you work with – regardless of their job title – Good Job!  Not only does everyone deserve to hear positive feedback but it will help strengthen your relationship and set a good example.  People tend to “pay it forward” when it comes to recognition.  When they have heard positive feedback about their own performance, they are more likely to recognize the contributions that they observe by others.

Here are a few resources on developing your own style of recognition:
The 1001 Ways to Reward Employees by Bob Nelson

Retaining Your Employees: Using Respect, Recognition, and Rewards for Positive Results (Crisp 50-Minute Book) by Barb Wingfield (EASY QUICK READ) – Great website that offers daily emails on leadership & motivation technique

Offer your suggestions on recognition!  What’s worked well in your organization?  What experiences have you had with recognition that’s gone miserably wrong?

October 18, 2010 at 8:03 pm 2 comments

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 39 other followers

%d bloggers like this: