If you work for a creative organization, you’ve probably spent time looking for a resource planning tool. At previous jobs I’ve held, whenever a new project manager came on board, the question “How did you do resource planning at your last job?” would invariably come up. Everyone had a different answer, but would usually add that whatever solution they had been using, the company was looking for a better one.
For resource planning, the process can range from every PM spending most of their time doing data entry (and re-entry) into an all-encompassing-mega-tool to basically “winging it” and hoping for the best. Resource planning for creative work is not the same as resource planning for a factory and comes with a lot of challenges—one being that client timelines can change daily, so whatever tool you use has to be flexible. You also want to be able to accurately forecast a creative person’s utilization without them feeling restrained.
When I first joined Think Brownstone, the company was rushing headlong into the transition from small company to medium-sized company; from being able to manage projects through organic communication and tight-knit project teams to needing scalable tools and someone focused on project management without having to do double duty with another role. We needed a good tool for resource planning.
Here are some features that we identified as essential to make the tool useful:
- Show us people’s planned utilization per week, per project (in hours)
- Filter that same information by department
- Forecast out far enough, accurately enough, to help predict hiring needs
- Accommodate projects in the pipeline
- Allow multiple users to access it at one time
- Be easy to use
Bonus points if it…
- Ties into our time tracking system
- Allows us to see project budget health
- Has a reasonable price point
- Looks great and is a great user experience
We knew that any effort to improve resource planning should start by taking a look at project plans. Maybe the resource planning tools we were using were fine, but our project plans were inaccurate. Resource planning is only as useful and accurate as the project plans that inform it. We ended up with MS Project for all our project managers, running on a Parallels / Windows solution. That gave us the tool we needed to tighten up our project plans.
We also knew that people don’t like to be called, or treated like, “resources”. We didn’t want to use a system that turned every moment of the day into a task to log and squelched the rare phenomenon we get to experience – the feeling of enough space to stretch out and be creative when working for clients.
None of the available tools seemed to check all the boxes on our requirements. What we decided to do was modify our current Excel solution to meet our needs. We created more sheets in our workbook and used our pivot table skills to create a sheet that told us who was booked on what for how long, and when. We filtered the data by department and included pipeline projects. We used the data to forecast hiring needs. The price point was perfect and we even found a macro that allowed us to “lock” the file when someone else on Dropbox was accessing it. There is some manual input of data from our time tracking system, but otherwise it does everything we need it to do.
Below are links to all the tools we researched and ultimately did not use. None of them quite did what we needed them to do. Start with this list and maybe you’ll find what you need…or maybe you’ll do what we’ve done and run with air-tight project plans, clear team communication, and a light-weight excel workbook until you find the right solution for your company.
What are some resource planning best practices you’ve come across? Have you found the perfect resource planning solution?
Resource Planning Tools:
- Basecamp (We use this, but not for resource planning)
- 10,000 Feet
- eResource Scheduler
- Pivotal Tracker
- Netsuite Open Air
- Team Work PM
- Project Bubble
Over the lifespan of a web-based product, each new feature that gets added will increase the complexity under the hood. This means that working on it and making future updates will most likely become progressively more difficult over time. It’s not uncommon, even in large companies, for this difficulty to eventually become so significant that further development grinds to a halt; this is what developers call technical debt. The good news is that the risk of this happening can be mitigated; it just requires that developers be given the time to set up the proper tools and automation to ensure your web product will scale gracefully.
There are a lot of productivity-boosting tools out there to help your dev team, but to give you a sense of the kinds of purposes they serve and the efficiencies that can be gained, I’ll provide a high-level overview of two of the biggies:
CSS Pre-Processors (Front-End Developers)
A fundamental goal for developers is to make code more re-usable and DRY (don’t repeat yourself). DRY is a coding principle that basically says “if you need to copy and paste some code to do the same thing in more than one place, you should instead create a single function (which acts as a shortcut) and use that function any time that you need that code.” Enter the pre-processor.
Pre-processors can accept variables for things like color, for example, so if your company has a specific blue that it uses for all links, it can be saved as a variable (like a function, this acts as a “shortcut”) — reducing the likelihood of someone say, using the eyedropper tool in Photoshop to try to guess the color of the logo, getting it wrong, and then adding a new (and incorrectly deviated) color to the CSS files of your product. Other examples are functions that lighten or darken colors, helpful because colors can be derivative of a single color. So, those blue links that turn dark blue on hover? If I use a pre-processor to make them darker, and the business team later changes them all to green, all I have to do is change the code once and all other instances (sometimes in hundreds of locations, with a wide array of slightly deviated colors) will be updated automatically. Sounds like a no-brainer, right? You’d be shocked how often hundreds of identical changes are still made manually.
Code Validation & Testing (Front-End & Back-End Developers)
Sometimes referred to as linting, the benefit of this process is that routine/mundane (but crucial) checks that should be done with code can be automated through tools like Grunt, JSHint, Grunt-JSHint , CSS Linting, and many more. These tools will do the boring but critical tasks like checking for missing commas, verifying the correct number of parentheses/brackets, and plenty of others. With Grunt in particular, a “watch task” can be created so that every time code is saved, this check happens automatically. While we do our best not to make mistakes, we’re human after all—but since these are objective tasks that can be done with 100% accuracy by machines, it’s in our best interest to let them have at it.
The Big Leagues
The Bottom Line
If your developers don’t already know about these tools, it’s a good idea to make the investment in providing them with the time to get familiar. These tools will not only increase their productivity, but instill a greater sense of confidence in managers as well as the product itself because they take large amounts of cognitive overhead and stress off of the development team. If your team has process-improvement-minded developers then they will be more than happy to be allocated time to experiment with and learn whichever tools are the best fit for the product they are maintaining. Now that we have these tools at our disposal, bolting awake in the middle of the night thinking “Oh no, did I forget to do step number 483 when I pushed the latest release?!” is less likely than ever before. But I’ll repeat the core message here: development teams are usually being pushed to create new features (and in doing so, increasing cognitive overhead and technical debt) because those features are assigned a higher priority than the “grooming” of a product which ensures that it will remain lean, fast, and efficient as it grows. Don’t make that mistake.
There’s a lot more that could be said on this topic, and I’m happy to spar in the comments or post again on a specific nuance if anyone is interested—but this is meant as an introduction to a principle and an idea, rather than a comprehensive list of all the things you could do to make your team faster (which would be very long, conceptually dense, and subjective). Looking forward to the continuing conversation!
If you live in the Northeastern United States like I do, you know what a never-ending throat punch this winter has been. Here around Philadelphia, we’re currently in third place for the all-time local snowfall record, with more on the horizon as I write this. Great.
That’s not to say I don’t enjoy the winter. Having established my circadian rhythms in the all-four-seasons zone, I genuinely delight in the coming of each new season, yet similarly despair in the depths of both Winter and Summer (Spring and Fall can do no wrong). Despite the allure of the near-perfect weather of San Diego or the Mediterranean, I’d be hard-pressed to give up my seasons — even knowing that with them come mowing in a humid 95º and shoveling a foot-plus of heavy, wet snow in the breaks between conference calls.
I feel like there’s something to learn in there for the UX designer. Even Southern Californians I talk to admit to seeking a break from their perfect monotony in the mountains to the east. Yes, your designs should be logical and employ some level of predictability, but that’s not to say that variety doesn’t have its place. It’s that variety and occasional unpredictability that can help bring the delight in Research > Design > Delight. The trick for us – where we earn our keep – is helping our clients recognize the time to be predictable and the time to throw in a mid-winter heatwave.