Creating a Transition Plan – Effectively Moving On

In a fast paced consulting environment it is very common for resources to change projects several times per year – especially for junior resources.  Commonly, at Rosetta, we are asking junior level business analysts to assume more responsibility so more experienced business analysts can take on more value-add roles with our clients. This is the basic leverage model of many consulting firms.

This presents a real challenge for the person “rolling off” the project – you must…
1. continue to operate at a high level on your current engagement
2. effectively transition your current responsibilities to someone else
3. quickly become effective on your new engagement

In this post, I will visit item #2 – effectively transitioning your current responsibilities to someone else.  I believe that, of the three points above, this is the most critical.  Being effective at #2, will allow for minimal impact to your current engagement (#1) and maximum impact to your new engagement (#3).

There are three keys to an effective transition…
1. Task Transfer
2. Shadowing
3. Structured Oversight

Micromanagement

A few days ago I read this article from the blog, Coding Horror.  I read it fairly frequently even though it has a very technical slant to it.  It claims that if you answer yes or kinda yes to any of these questions – you are probably micromanaging.  I shared my answers below – in some cases I disagreed or felt it wasn’t as black and white as the article makes it out to be.

1. 1. Do you pride yourself on being “on top of” the projects or your direct reports? Do you have a solid grasp of the details of every project?
2. Do you believe that you could perform most of the tasks of your direct reports, and potentially do a better job?
3. Do you pride yourself on frequent communication with your employees? Does that communication include asking them for detailed status reports and updates?
4. Do you believe that being a manager means that you have more knowledge and skills than your employees, and thus are better equipped to make decisions?
5. Do you believe that you care about things (quality, deadlines, etc.) more than your employees?

Here are my answers to those questions -

Get a Client to Say Yes

I found this article on “getting a client to say yes” to be fascinating.  It really made me stop and consider how I conduct conversations with my clients.  Not just in a situations where creative design or direction is being discussed (not my strength) but in all conversations. The article starts with a 35 minute presentation and ppt and is followed by a fantastic write-up.
How do YOU get a client to say yes? Post your thoughts in the comments below.

- Bill Weber

photo credit: wallrevolution

Scrum – a Project Management Approach

Scrum – noun

1: a rugby play in which the forwards of each side come together in a tight formation and struggle to gain possession of the ball using their feet when it is tossed in among them; also: the arrangement of players in a scrum b: a usually brief and disorderly struggle or fight.  2a: (British) madhouse.  2b: a usually tightly packed or disorderly crowd

The Scrum I am talking about is none of these.  Scrum is an iterative process of software development that is typically used with agile softward development.  Even though it was intended to be for management of software development projects, it can be used in running software maintenance teams, or as a program management approach.

I have found it to be very effective in managing ongoing projects – meaning projects that are not building something from the ground-up.  If you read my post on Context Switching, you will remember the diagram of “Total Demand” to “Completed Work” – Scrum is the way in which I manage the “Total Demand”.

Work/Life Balance

This is something I rememeber my Dad always telling me when I was (still am?) growing up – Balance.

You can break work and life into more granular pieces.  Life – immediate family, extended family, friends and self for example.  Work – subordinates, superiors and clients.  The simple concept is not to let any one of these, or “Work/Life”, to dominate your time and energy for an extended period of time.  You may work 65-70 hours in a given week, maybe even 3 weeks in-a-row – you will be out of balance for a period of time.  The key is to stay balanced over a long period of time – their will be ebbs and flows.

A blog I read on a fairly regular basis, The Art of Manliness, just did a piece on the Work/Life Balance.  While their target audience is men with kids, the concepts apply to both genders.

How do you deal with the Work/Life balance? Leave a note in the comments.

- Bill Weber

photo credit: star5112

Context Switching

There are lots of issues to be concerned with when leading a team – who is dependable, who is not?  who is your go-to problem solver?  how do you raise the overall “level of the water” on your team?  All valid concerns.  However, what I struggle with the most is the having a team that must deal with planned strategic-type work and also ad-hoc requests – or better yet, context switching.  Context switching is the changing of focus for one or more of your team members – it is absolutely a productivity killer.

The simple formula that I use to go from a pile of work to the delivery of work is a series of filters or stages… Total Demand -> Prioritized Demand -> Capacity Constrained Demand -> Completed Work

Total Demand – this is the total “list” of all things that must be completed.  It is important to get EVERYTHING on the list and accounted for – if everything is not on the list to begin with you are setting yourself up for failure.

Prioritized Demand – this is a forced ranking of Total Demand – it must be a forced ranking… no ties.  Once forced ranked or “prioritized” the top items should be given estimates – they can be ballpark.

Capacity Constrained Demand – this is understanding how many hours per week (month, deployment cycle, etc) your development team has available.  Example – you have 4 developers on your team.  You assign 40 hours of work per week to each developer for a 4 week development cycle – that is 640 hours of capacity.  Your team can work on the first 640 hours of highest prioritized items.  Clearly this is a simplistic scenario.

Consulting Basics – Dos and Don’ts

Here is a presentation that I gave to a couple internal areas a week or so ago. The presentation is a compilation of positive and negative practices that I consistently see happening with regard to meetings, email, presentations and documentation. While some of this may seem like common sense – I see these same mistakes being made time and time again. Take a couple minutes to read through this presentation and try to internalize these “dos and don’ts”.

Consulting Basics – Dos and Don’ts

- Bill Weber

photo credit: EJP Photo