“I Sing The Body Electric” was one of Bradbury’s better pieces of writing. Sometimes, when I apply it to my techno-business trade of choice (bringing to market usable mobile products), out of my imagination comes titles like the one on this blog posting. “I Sing the Body Electric” has a ring to it that is right up there with
trip the light fantastic
Bradbury’s book, “I Sing The Body Electric,” gets at mysticism and being involved with things that don’t always have concrete explanations. Trip the light fantastic touches on moving in a nimble way through a musical composition – or, as I like to say it, it connotes something profanely artistic that is born of improvisational genius.
Somehow both concepts are fitting to technical project management. Grip your trousers tight, folks, because this blog just got a bit more artistic.
It’s common for people to try and deal with technical projects like the building of a mobile application as if they are fixed things. Contracts are signed, people are hired, and schedules are set. Then, often times the expectations for all involved are said to be set in stone and inflexible. At least, that’s what the engineers are often led to believe. But then life always intervenes once a project gathers momentum.
A project begins to take seemingly unpredictable twists and turns. Stress mounts, and suddenly the work can only seem to get done at great personal sacrifice. That sacrifice can mean unbearable amounts of overtime, or even bosses demanding people finish the projects the way it was originally conceived, and “on time and as expected,” at the risk of people losing their jobs.
The Bradbury Connection
As our pre-concieved notions of how a project should be executed give way to the realities of every day life, people seem perplexed. In this way managing a software development effort can be like Bradbury’s story. It becomes a perplexing journey on an experience that is hard to explain.
How do we deal with that, especially when we know that project after project may carry the same “do or die” theme? We can either clutch to our rigid project-day-one ideas and hope that someday we find that one project that “is executed perfectly.” At least you get the luxury of blaming failure on a “bad project.” Or we can the trip the light fantastic and move through the project in an appropriately improvised way; adapting to ever changing circumstances – new requirements, changes in staff, under bidding, and technical failures beyond our control, just to name few.
So, how do we perform well on our teams in that environment? Having some concrete tools to improvise with can certainly help. And that’s where this blog posting comes in. I submit to you that resourcing can set up a project to start off on the right foot, and on a day to day basis help everyone on a team adjust to the unpredictable nature that is inherent in working on projects that involve people with wildly different technical skills.
- [ree-sawrs-ing, -sohrs-ing, -zawrs-ing, -zohrs-ing, ri-sawrs-ing, -sohrs-ing, -zawrs-ing, -zohrs-ing]
- 1. The act of assigning one or more resources to a particular task for a period of time.
- 2. Causing people, equipment, or to be organized to accomplish a particular task or goal.
- 3. Removing un-necessary resources from a group, team or resource pool that is assigned to a task.
- 4. Arranging one or more sources of supply, support, or aid, especially one(s) that can be readily drawn upon when needed; expedient
- 5. Assigning tactical assets to accomplish an immediate mission.
- See also: Resource, wikipedia
That’s my definition. If you type “resourcing” into google.com, you’ll actually see a definition that Google provides. My definition is pretty similar to that one. But, if you look in the dictionary, there’s a chance you won’t find the term “resourcing” So, I made one up based on how I relate to the problem of pulling together resources to complete a project.
I think this is also a common term to use in graphic design houses by project coordinators who are trying to assemble in-house people to work on specific client projects. One multimedia design house I worked at actually had a “resourcing meeting” every week where the project coordinators had to fight over which engineer was working on which project. It was a fun and entertaining mess to watch – mostly because it was my time that people were often fighting over.
You might enjoy that notion too, right up until the day you realize the project “managers” contributed to some factor that led you to working 70 hour weeks to compensate for some mis-calculation. Under bidding, an incomplete schedule, inability to find enough people to help, faulty computers, or even insisting people on the team commit to tasks they are not technically prepared to handle. These are but a few examples, but they are also the inspiration for this blog, because frequently, when it came to engineering, the project coordinators got resourcing wrong. More on the bad side effects of a botched resourcing job later, below.
The Problem Resourcing Solves
You’ve got a project to do. Your team members may be paid by the hour, salaried, fixed priced, or somewhere in between. Whatever – that’s gets at how the project is expensed, but not how it’s executed on the day to day and has nothing to do with the project’s completion date. Regardless of what the billing structure of your contract is and how you pay people, you always need people and resources aligned to do the work.
Assigning people to your project and coordinating their availability is a challenge that exists on any project. How well this is done can determine whether or not a project succeeds. Resourcing helps solve this problem.
Resourcing As A Tactical Project Strategy
Resourcing can be thought of in a number of ways:
- “aligning the stars”: putting together all the things that a project needs to be successful.
- tactical project planning: deciding what resources for a project are in play, when they are to be used, and where, etc.
You can pick any phrase that has to do with picking the right people to get today’s job done. The job at hand. The one thing you’re going to get your team focused on to make money this week.
If you have work you need to get done this week, just ask yourself the who, what, where, when, (but not why) of the week’s work. I say don’t ask why, because I assume you’ve already answered that question. If you need a reason, here’s a “why”: to make money.
Right – resourcing is also about doing your work with what you have in a profitable way. I don’t mention this in the definition I have above. But, it’s important to understand that resourcing is about finding the right mix of people and things to accomplish a project that you can afford to work on. There’s a balance between capability and profit you can aim to achieve.
However you define profit, or “getting ahead” is up to you. But, the idea with resourcing as a tactical strategy is to find the people and things you need to execute your project without going broke. For example,you might choose to delegate everything – that is, resource your team so that you don’t have to do any work at all yourself because you’re busy on higher priority tasks. And, you might be willing to do it regardless of cost or financial profit. While not necessarily realistic, that’s still “getting ahead” in one way, and a perfectly valid way of looking at resourcing.
Depending on your role your boss might require you to watch the bottom line, but running a profitable project is another discussion I’ll leave for a different blog entry. For this blog, resourcing is just about getting your people and equipment together.
Some Basic Resourcing Components
So, let’s say you run a consulting firm and you’ve landed a project. Your sales staff is really proud. You have all the people, equipment and office space to execute. Everyone’s motivated and ready to start.
Now what? You tell everyone to show up and work … do “their magic” right? No. You have to give everyone a sense that there’s some organization going on. Being too hands off can quickly slip you into the mysterious realm of being an irresponsible project manager. This is where resourcing can help.
When it comes to resourcing, I believe the project size doesn’t matter – it can be a big project or a little one. In fact, it may be better to try out the recommendations in this blog on a small project first. In some ways, practicing good resourcing on a small project is more important than on a big project. If you have a problem that you run into on a small project, a bigger project will just magnify that problem. And that can be embarrassing.
Component 1: Scheduling
A gantt chart that identifies specific people, but assumes that nobody has sick time or vacation time. Is that realistic? (source: conferencebasics.com)
Chances are, the client wants to see a schedule, and have you itemize what you’ve brought together to get the job done. So, a schedule is a critical component of resourcing.
There are a number of ways to represent a schedule: a simple list will do. But you can also use calendars, gantt charts, dashboards, and so on. Here are some helpful links:
The thing about a schedule is this: whatever form you put the schedule into, it must be changeable. There is one guarantee that you have on any project – the schedule will change. In the military, it’s often said that the first casualty of a war is the plan. So, why would we expect our civilian project plans to be somehow magically concrete? I think it’s dangerous to think that way. A project will change right under your feet and you might not even notice it … unless you know what you’re looking for.
One of the key things to look for is the time your team puts into updating the project schedule: too much time spent on scheduling can cause chaos, but not enough time can lead to a disorganized mess. So, getting this balance right can certainly help. Here are the basic things involved in scheduling that will probably be useful to you. You may have other things, but this could work at a minimum:
- Who is working on the project and when?
- Have you factored in vacation and sick time?
- Have you given the customer a reasonable expectation of timelines?
The only other thing I’ll say about scheduling is that if it doesn’t change on any given day, and all the project updates you see indicate “no changes” then that might be a sign that someone is not paying attention to the factors that can affect the schedule. I’m constantly amazed at how often I’ve seen Technical Project Managers do this, despite the emphasis placed on knowing when a project is scheduled to be completed.
It’s just plain hard to see what adjustments to the project need to be made to keep it on time if you don’t spend enough time keeping the schedule updated. Daily updates and adjustments are a good place to start.
Some Gantt Chart Alternatives
The simplest form of a project schedule is just some text on a note pad. Here’s one I created for a fictional project where musicians and Siddhārtha combine forces to create a mobile app:
Sometimes simple, handwritten Charts are the best. They need to be in a form that can be updated daily throughout a project as conditions change.
This took me only about 5 minutes to make up. I made sure I added some markings to indicate who has sick leave available, as well as floating holidays. All of which these people have worked hard for and deserve. In the right hand margin I indicate there is a potential to slide the project deadline by 16 total days: 12 sick days and 4 floating holidays. Naturally, it would be best in this case to set the client expectation to receive the final app on the 1st of August.
However you get the information onto paper is irrelevant. The key is to indicate indicate who is available, their specialty/role on the project and when they will be available to do the work. And most importantly, to be able to visualize what would happen to the project if any combination of people become unavailable for a period of time.
If you’re into fancy graphics, then these might appeal to you as well:
Cause and Effect Charts, also known as fishbone charts. (source: brighthubpm.com)
Cause and Effect charts are some of my favorite. They’re also called fishbone charts. You can put any kind of data on them that identifies factors which impact a goal. They’re often used to identify issues related to problems, but you can easily see how they can be used to identify factors of successful or completed project.
Component 2: Computing Power
What computer equipment is available to use? Do you have to set up a VPN or other infrastructure to meet client needs? Is your build system already overloaded? The list goes on. But I think you get the point. The idea here is to constantly be aware of whether or not the computing equipment you have is overloaded. Here are some factors you might add to the mix:
- How many computers are available?
- Do you already have a requisition request for a larger build system? Your engineers might be telling you you’re on the verge of having an infrastructure melt down if there are a few of these.
- How long does it take to roll out all your builds? Particularly important if you have a monolithic build system that is used to roll all of your company’s builds. It’s good to have one machine to roll all your builds, but is it overloaded or not? On an Android project, for example, it’s not uncommon to have a build system that contains terabytes of code which can include the entire Android source code base.
- Are your engineers fighting with system setups and slow internet connections?
One way to tell if you’re under powered in the hardware department (no snickering, ladies) is to take note of how much time your engineers in particular deal with system setup issues. A basic acid test can be this: take metrics about your environment such as processing power, disk space, and RAM available on your machines. Run some metrics to see how taxed that equipment is.
In other words, size matters when it comes to getting things done. Alright – fine, snicker away.
Component 3: Identify your Mavens
It could be said that your team is right for any project they are technically prepared to execute. And everyone likes to think they’ve hired perfect engineers – rockstars if you will. But, are you aware of who is an expert at implementing applications with specific technologies?
Can you identify all the technologies that your team has built into applications before? You may have a group that is well versed in writing apps for a particular platform (e.g. Android or iPhone devices), but have you identified all the features of those platforms that will be involved in you your final deliverable? How many people on your crew have actually delivered an application using those features?
For example, if you’re creating an app that uses GPS and Near Field Communciations, do you actually have people on your team who have built those features into any application? Pick any feature of a mobile device – the question I am asking still applies.
I’m not suggesting that failure to have implemented something like GPS into an mobile app is some sort of deficiency. It just means your team mates haven’t gotten around to it. So, what I’m saying is that it’s healthy to understand what specific technologies (esp. mobile features) your team mates have mastered in the past, and give them a safe place and the time to master things they haven’t yet.
Here’s a simple list of examples for Android 4.0, which it stands to reason nobody on your team has yet mastered:
- HTC’s 3D API.
- vsync timing, triple buffering, reduced touch latency, and CPU input boost
- hardware-accelerated 2D renderer
- Renderscript Compute
- Quick Settings
- Application Tray
- Dedicated User Spaces
- Daydream – yes, that’s an actual feature
- Lock Screen Widgets
- Native RTL support.
- etc …
That’s a very basic list of enhancements to Android 4.0. I’ve just scratched the surface. If your team is going to master those items, then it just stands to reason that they need time to actually write applications that utilize them. Ideally, they would do that in a non-customer facing laboratory before customers ask for those features to be put into their apps.
And most importantly, do other people in your company or working group know where those strengths in your team lie? One way to keep tabs on that is to itemize, feature by feature, things each member of your team has built into an application.
This is where an in office research lab comes in handy. In terms of money, the effort to establish this can be limited to the commitment of individuals on your team. Especially if you already have a development group set up.
For example, I’ve always had a job that requires me to spend 20% of my time (in some cases more), learning about the state of the art of my field and applying it to real world problems. And I’ve used that time diligently to try new things out, like Near Field Communications. The beauty is, it’s not necessary to wait around until a client demands that you build an application with those things.
You can start a side-project with a somewhat real-world application that is designed to build some experience with “the new thing.” The idea here is to align your team with projects that utilize technologies they’ve already mastered as engineers. But it’s also necessary to give them all time and a safe environment expand the list of “mastered technologies”.
My suggestion is, quite simply, to create a laboratory type environment that lets you make mistakes at a time where there is no time pressure. If you do that, for each technology you will ruled out all the things that don’t work when baking it into a product. The only thing left will be the “right way” or best practices, and your rate of coding production during billable projects will increase dramatically.
This is also why it’s useful to make conference attendance (e.g. Google I/O) a mandatory event every year.
Component 4: Have a Gameplan To Deal With Busses
I call this component the “hit by the buss” component. I encourage you to use your imagination to get in touch with what would happen if one of your co-workers got hit by a bus, or gets ill for a long period of time. Go ahead … cry. You’ll miss that person. As an aside, I’ll suggest that if you aren’t moved by that prospect on a human level chances are you despise or have objectified your team mates – the same people you also happen to spend a significant part of your life with. I’ll let you talk that over with your shrink on your own time.
Where was I?
The obvious human tragedy is a big enough thing to deal with, but everyone will still be counting on your mission being completed. Again, I turn to how the military has found a way to deal with these kinds of things. On any particular mission, a certain amount of people can end up missing or (through no fault of their own) not able to help the team complete its mission. And yet missions still get completed. Seemingly on time and in the most unpredictable of circumstances. There’s a lesson or three there that we can learn when it comes to tactical project planning.
One of the most effective ways to deal with this eventuality is to require your team to spend time time sharing knowledge. And here’s an acid test to determine whether or not that’s been done properly. On any given day, can employee “B” sit down in the chair and do the work that employee “A” has already started?
I like to ensure that this can happen by using six simple work lifestyle choices. This may work for you as well:
- Code reviews on every code check in. This involves a developer calling upon one of the people on his/her team to look over their shoulder while they explain in details what decisions they made and how those decisions were implemented.
- Documentation standards. Don’t roll your eyes at this one yet. But it does work. Technical specs, in-code documentation and comments are all “incomplete works.” They don’t create a running applicaton so they don’t have to be detailed. But are they all detailed enough to let everyone on a project understand what is being accomplished and where in the code it’s being accomplished? I’ll write more about this on a different blog entry.
- Daily engineering meetings. People hate these, but as long as they are short and to the point and relate to the work that is going on, they’re never a waste of time.
- Collaborative working lifestyles. Do your employees talk shop a lot? It’s good to allow them time to do that on a daily basis. They don’t have to like each other, but they do have to respect each other enough to sit in the same room and talk through ideas.
- No hidden technicals. If you have a team mate that always glosses over hidden details about their code or is too afraid of exposing their work that might be a sign that you’re not prepared to recover from a lost employee.
- Require people to be articulate. It’s true that developers write software so that it can be read by another program (e.g. a compiler) and turned into an application. But it could be said that that’s not the audience engineers write software for. I submit that engineers write software for an audience and that audience is other engineers. Does the in-line (code) documentation explain in correct and plain English (or whatever language you communicate in)? Does the logic in the code reflect that? When the logic of the code, the in-line documentation, and the technical spec are read by a human is it all consistent? Basic communication skills here are key.
Those six items of the “hit by a bus” component may not seem like a resourcing problem, per-se, but the degree to which they are used can definitely affect your options for putting people on your projects. So, while you may not be the person to solve those problems, it’s wise for you to at least make a mental checklist as to the state of things so you can make recommendations to your team mates.
Don’t Take My Word For It
I’ve tried to steer away from theoretical project management approaches and stick with some practical tools to help you stay on top of the work being done around you, regardless of your role.
So, let’s say what I’ve written here doesn’t appeal to you at all. You get an initial schedule approved by your boss/client/whomever and then stick in your desk drawer, hoping that the project will “just work out.” One thing you might consider, and this is what I mentioned about projects gone afoul above is this:
Clients will expect that any underestimation by the project manager will have to be made up in one way or another. It’s usually through relentless and un-necessary overtime. Especially when client expectations begin to fall out of alignment with the reality of your project’s work pace.
For example, the work of employees who can’t show up to do their job, regardless of the reason, will ultimately fall onto the shoulders of their team mates. Or, at best, employees returning from a well earned vacation will be punished with unreasonable overtime. And for salaried employees that means working for free.
Burn out is right around the corner. Talk about a morale buster.
Go ahead, just test that theory …
In this blog posting I went over the basic concept of technical project resourcing. And I discussed some things that I’ve found work well when it comes to pulling together a working team to accomplish a task. Your mileage will vary, but hopefully it will give you some constructive things to think about.
In short – it’s all about the setup. The moral of the story is that the more you have the right resourcing components in place, the better chance of success you’ll have and best of all, the least amount of variability you might see between planned completion dates with actual completion dates.
Notice that I didn’t discuss quality of the work that each individual contributor produces, rates of work, etc. Those, too, are topics for a different blog.