Thursday, December 03, 2009

Turning an amorphous blob into a chaotic ball

You're overcomplicating it Wendy.
- SysAdmin Guru

So I've managed to get a baseline technical process figured out for the awkward project.
- Person enters a staffing request
- Staffing request goes to manager
- Manager assigns a resource

Pretty straightforward.

Where I got stuck - what resources, as a manager, do I have to determine which resource to assign?

Well...there is (supposedly) information from the time sheets people (supposedly) have been entering.

There is also (supposedly) information from the projects that have (supposedly) been added to the system by (seemingly random) managers.

Assuming that we have the information from the time sheets (past trends, actuals) and information from the projects (future needs, projections), there should be a way I can take the Time and Project information so that I can make informed decisions on resource allocations....right?

And this is where Wendy learns that the modules of this awkward project are more independent than they first appeared.


Now that is just the technical issue. A conversation with the SysAdmin Guru and his friend the Tech Goddess reminded me of some of the deep systemic, process and cultural issues that exist.

Combined, the SysAdmin Guru and the Tech Goddess have almost 50 years of experience in technology. They have been with the organization for 25 some-odd years. I wanted to talk to them because I feared that I was going down a rabbit hole and needed some insight.

Here's what I learned:
- We possess a haphazard project management process

- Though the Main Muck is trying to establish some accountability for time, timelines within the project are still flexible - usually hurting people who need to perform tasks later in the project.

- There is no accurate assessment for how long something actually takes. The Tech Goddess suggested that there are multiple tools out there for benchmarking tasks in our field. "No one seems to use them."

- There is no accountability for budget as long as you get things done "on time."

- There is a lot of bleed between operations and projects. Someone who is on a project who gets pulled for operational tasks can impact the project.

- There may be an issue of skill-set among the staff if you attempt to make 1 team operations and 1 team projects.

- For those who are more project-based vs. operations-based - there is no clean handoff (or NO handoff in most cases). What happens is that folks who tend to be dragged into projects wind up with an ever-increasing set of operational responsibilities, which then impacts time spent on projects.

- Because there has been a change at the top of the organization - we have a lot of folks running scared. As the SysAdmin Guru put it "No one is willing to tell the truth."

All of this goes back to the main question - which has to be addressed to the Main Muck

What are we trying to accomplish and what does "success" look like?


Anonymous said...

It is very hard to account for the variability of the human being. You can plan all you want, but as soon as one person along the chain does not behave the way you predicted, effects ripple and the process is busted.

Bryan Hundley said...

Would it be feasible to ensure every resource (person) has a designated backup on a project so that when the primary resource is pulled to operations the backup can slide into place? Of course the backup had a prior task, which should have it's own backup who will slide in place. It should recursuvely fill the gap until eventually finding someone to step up who does not have a backup for their task simply because their task is non-essential and can be put on an indefinite hold.

Or is that not an option?

Wendy said...

Bryan - I think the "recursive backup" is what they are trying to do. Some departments manage to do this more successfully than others - and I think it's a result of skillset.