We all know staffing is critical when executing a custom software project, but unless you’ve worked in the business, the timing and intricacies of the staffing decisions can seem at best opaque, and at worst like smoke and mirrors. In this two-part series, we’ll look at the three critical points for staffing a client’s project. We’ll start with hiring the new employee and responding to a new lead and then discuss managing the development team in the second blog.
Your Project Starts before You Even Contact Us
The first and maybe most important time to consider staffing for a project is when you hire and interview an employee, and comes long before you’ve even reached out to potential vendors. Now, the point at which this employee either makes or breaks your project may be weeks, months, or even years in the future, but this is the right time to start tracking the vital information that will make this new team member either a buoy or a lead weight on a software project. What is their skill set? Are they a generalist or a specialist? What is their domain experience? Are they a background, head-down, magic-maker who might choke when put in front of a roomful of clients, or do they shine in the spotlight and thrive on communication? All important criteria when making a staffing decision. Software projects need all types of people, but not every role is well-suited to every team member.
First Contact between the Client and the Software Development Company
The second important staffing point is the moment the potential lead hits enter on their form submission (or picks up the phone to reach out to you for the first time). As a sales and accounts professional, when I’m reading a client’s project breakdown, I’m already considering resources to bring in for the sales effort. I probably know more than the average person about software, but at some point during the sales process, I’m going to need the support of our company’s experts to help tease out enough detail from our potential client to give us a good 30,000-foot view of their software project. I’m thinking about the client’s domain, about the software user base, about the technology choices, about how important UI is to the client, and all of these decisions coalesce into 1 or 2 key employees at our firm that will help me bring this lead in successfully.
Assigning the Right Developer
I want a developer who understands the business model and also the technology necessary to execute the project. But that’s usually not enough. Just because someone understands something doesn’t mean they’ll be able to communicate that understanding or instill confidence in our clientele that we can help them achieve their goals. I want someone who is both personable and confident in their ability, because that confidence is going to come through on the series of phone calls or video chats we have with our clients during the sales phase. If the client is very focused on UI, I want one of our UI/UX experts on those calls along with a developer to show the client that we’re taking their concerns seriously right from the start, and that we have the skills necessary to help them achieve their goals.
Involving the UI/UX Designer
And finally, when I am choosing the developer and UI/UX designer to help with the sales lead, I want to know that they are going to track and note the client’s needs clearly and efficiently, both for the client’s sake and also for the eventual project team’s sanity. The knowledge transfer from Sales to Development is key. It reassures clients that they’ve made the right choice when they get on a kickoff call with their Project Manager and he or she is already well-versed in their software needs. It shows that we know how to communicate internally, and that our processes are sound. These are all key attributes a client looks for in a software developer either consciously or unconsciously. Often when a client chooses a different vendor, they are doing so because something just didn’t feel right during the sales process, and though they may not be able to put into words exactly what the problem was, it often comes back to one of these points: Competence, Communication, Confidence.
In the next part of this series, we’ll discuss what’s involved with choosing a team to execute the client’s vision, and how important it is to evaluate and re-evaluate the development team throughout the project.
