You need the right number of people to work on your project. Too few, and the work doesn’t get done well or on-time, causing stress to all concerned. Too many, and you spend more time in “management” – and wheel spinning – than getting the work done.
Scheduling the necessary resources to complete a project is critical. If you do not schedule the right resources (specifically, the staff necessary for the given project’s tasks) you are less likely to deliver software that meets expectations. Unless each team member is committed to the project with the same like-minded vision, the software likely will fall short of project goals and requirements.
These are lessons, alas, that we often learn only through experience. So I asked software developers and project managers, “If you could go back to your younger days and tell yourself one thing, just one thing, about scheduling resources, what would that be?” Perhaps these insights can help you avoid some excruciating pain.
Resources are Not Interchangeable
Regardless of any advice offered by your project management tool or an executive, software development resources are not interchangeable, learned K. Alan Robbins. Robbins, who started programming in 1979, is founder of Moose WorldWide Digital, a website and application consulting firm.
Robbins lays much of the fault with tools like Microsoft Project. Project works fine to manage construction projects, such as building houses and buildings. The construction industry uses resource pools that consist of generalists such as excavators, plumbers, dry wall hangers, and framers; each performs different tasks and do not see a single task to completion. In this case, Microsoft Project’s resource leveling may be relevant; it assumes that one resource of a given type (a plumber, for example) is exactly the same as any other (plumber), except for their work schedules. But project management based on Microsoft Project (and its ilk) don’t match the software development lifecycle, Robbins says. “For 90% of software projects, this methodology is inherently flawed. The developer who started the widget algorithm has to be the one to finish it. The guy who understands the legacy system is the only guy in the shop who can build an interface to it,” Robbins explains.
Robbins wishes he could go back in time and warn himself about the number of times that executives have asked him to deliver projects sooner than he can reasonably accomplish. Typically, he says, it is because the executives assume that if they hire enough developers for the project, they can complete it faster. Robbins illustrates his point with a script of a fictitious exchange between a software project manager and an executive. Robbins explains, “Any software project manager who has worked in a corporation that employs laborers (as opposed to knowledge workers) has had this conversation many times”:
Software Project Manager: “Project X requires 100 hours of resources. Based on current resource assignments and the required skills, we can deliver Project X in three weeks. Here is the project plan.”
Executive: Glances at the plan and says, “So if we hire 10 contractors, we can get this done in two days, right?”
Manager: “No, we cannot. This project requires Bob’s attention, as he is the only person who understands system Y’s interfaces, and Fred’s time, as he understands the database.”
Executive: “Okay, so we need Bob and Fred. How many contractors do we need to hire to get this done in two days?”
Manager: “With all due respect, nine women cannot have one baby in a month. It just doesn’t work like that.”
Executive: “Don’t get smart with me!”
Manager: “But we can’t get this done in less than two weeks, even if we stop work on all the other projects that the critical resources are working on.”
Executive: “Find a way to get it done in a week.”
This type of conversation is also exemplary of the difficulty that the business and technical communities have in communicating their needs and constraints to each other when working together on projects. Lesson learned: Communicate with project managers and C-levels about the nature of software development projects and discuss the kind of working relationship that is critical to getting quality projects done.
Select Virtuous, Hard-Working, Committed Developers
Alex Genadinik is a software developer with seven years of experience and founder of Problem IO, a mobile apps development firm founded in 2012. “If I could go back in time and tell myself one thing about scheduling resources,” says Genadinik, “it would be to work only with developers who are talented, driven people.” Working with these select people permits these other developers’ vision to mesh with his. Otherwise, projects come in at a lower quality that fails to satisfy the client, with far more bugs than are acceptable.
“Even if the main product is done, a lot of the details are not as good as they should be. There is no polish to the work,” Genadinik explains. The sup-par workers just finish the bare minimum, and they don’t test as much. Genadinik has to struggle to get developers who generate low quality work to do their work at all. Genadinik says he doesn’t want to hover over his employees and make sure they get their work done. He wants his developers to find themselves fascinated by the project and to believe in it.
Working with clock-watchers is always painful for project managers – or anyone else who has to work with them. “ I had two developers working for me. One was the kind of person who when we went to lunch, he would still talk about the project. The other guy was the kind of guy that when we went to lunch, he was talking about politics, the food, anything but the project,” says Genadinik.
Genadinik would always have to ask the latter developer how things were coming along. The reply was always that he was not done. Even with frequent check-ups, Genadinik always found his developer had not made much progress at all, whereas the motivated developer would not need to be checked on at all. “That project was delayed so much that it was never completed. That was a big problem for me. That’s where I learned that you really cannot work with people you have to make work,” says Genadinik.
And if Genadinik could go back in time, there are a number of things he would do differently. “I would resist the pressure to ship the product just to make money ASAP. And instead I would focus on building a strong team as the foundation. A strong team will not only ship the product, but they are more likely to stick around and improve the product over time,” says Genadinik.
Most software is not at its best when it is first released. According to Genadinik, it becomes good by evolution and by developers improving it. Keep an eye on the long term, and don’t focus on the short term pressures and anxieties as much as possible.
“I would most definitely stop my business relationships with the people who don’t fully want to be there. I do that to this day. I hire very slowly and only people who intrinsically want to work on what I want to work on, or can show that they can be good employees. But I never jump into working with people now. I find a way to give us a little test period where we can feel out how it would be to work together,” Genadinik says.
By scheduling the necessary people with the proper skills, experience, and attitude and ensuring you have their time and attention through to a successful project completion, you will save yourself many headaches and foster good relationships with customers who will come back to you to meet future software development needs.
About the author:
- 7 Things Your Project Manager Wishes Developers Knew
- 10 Reasons Development Teams Don’t Communicate
- Corralling Heroes and Other Testing-Group Miscreants