Here’s the reality: most developers and managers work on projects for a specific end client. In other words, there’s a client who provides specifications and a team that builds to them (in the best-case scenario, those requirements are clear from the start, although they usually aren’t).
But could there be anything else? Of course: the way you work on a project is completely different from the way you develop a software product.
I’ve written about this before, but now I want to emphasize which aspects of project development need careful attention to prevent both teams and the company itself from being overwhelmed by a large number of poorly managed and underpriced projects.
Project development is full of details, and they all matter: the final result is a combination of things that have been done well enough, just as in any other professional activity. Neglect some of them, and it will show in the final result. Easy to understand, right?
I recently visited a company where I saw some of these circumstances: people eager to do things better, but exhausted by the daily battles, with no time to pause and see what isn’t working or what could be improved. You don’t have to be particularly smart to spot what’s being done wrong or what’s preventing things from moving forward. The problem is that you may have an idea, but it’s up to the team manager, their bosses, or the person in charge of the company to provide the means for people to work properly and decide to change the way things are done. This is also quite common: an inability to see that the results depend on it…
It’s not just about having the minimum infrastructure necessary; it’s also about maintaining methodological discipline in the way you decide to do things. I don’t think there’s anything more to it. The really difficult part is following that discipline and the established procedures.
I’ve created this short survey about the points we’ll look at below.
If any of the following sounds familiar, congratulations: you belong to a work culture that’s widespread in our industry (with low productivity and poor results that could be improved). Everything I’m about to say is obvious, and many will consider it basic advice. Still, are these practices followed at most software companies?
#1 A project with a realistic time estimate lets us work better
This is obvious, yet projects are usually won by cutting the schedule as much as possible and quoting too few hours… The result? Projects that have to ship no matter what, with too little time, so as we build them we’ll have to abandon good working practices (whether we know them or not—that’s another matter).
Basically, projects are quoted in hours, and the rates depend on the profiles of the people who will work on them (within the same company, some profiles are usually more expensive than others).
So if the work of estimating hours isn’t done well, there are two possible outcomes: we’ll push the team to breaking point with too much pressure (which isn’t just bad, it’s terrible), or the company will lose money (which isn’t good either).
The solution? Estimates should err on the high side and take into account the opinions of the people who will play the most important roles in the project, with some contingency added as well. That’s easy to say and difficult to put into practice, which is why commercial skills are needed to make it happen. This will probably result in a higher price that the client will try to negotiate down—that’s another important topic in its own right.
From a business perspective, you can’t go after every opportunity without realizing that, just as some companies work poorly, there are also clients you might be better off without. A difficult decision in times of crisis, of course.
#2 The specification should be as complete as possible
This is the great challenge of our profession: clients usually aren’t 100% sure what they really want or need. Even so, a good salesperson should be able to help the client and draw out what they want.
The important thing is to agree that, once the specification has been established, it shouldn’t change (at least not too much) as the project progresses. And if it does change—if we’re required to change it—we have to charge the client for the extra time involved. Of course, that won’t be easy either, but the client needs to understand that we don’t work for free; if the numbers don’t add up, they don’t add up.
That requires sales work capable of guiding the client toward the terms that work for us.
#3 Avoid spreading yourselves across too many technologies
Unless the company has a great many people with very different skill sets, it will usually be proficient in only a few technologies and know a little about some others.
When quoting a project, you have to take into account how familiar the team is with the technologies that will be used. If the team doesn’t know, for example, JSF very well, then we’re ignoring the learning curve (which means time) we’ll face during the project. It’s a hidden cost that has to be taken into account.
Let’s be honest: while some people spend much of their free time poring over manuals or building their own projects, many people don’t touch those topics outside the office.
The solution? Try to take on projects that use the technologies you know best: that’s a guarantee of productivity (and profitability).
In my opinion, there’s nothing worse than a team that tries its hand at everything (for readers in Latin America, the Spanish expression “darle a muchos palos” means doing many different things). We can only be experts in a few areas, so profitability and productivity will come from the technologies we know best. We’re talking about making a project profitable, not playing with MongoDB because it’s cool and forcing it into project X simply because I like it, not because it’s actually a good fit.
#4 Use some form of configuration management
The workday is full of small moments and details that we can handle well, do in seconds, or get completely wrong. Every detail matters, so a lack of smoothness at work comes from handling some or all of those daily details poorly.
Nothing affects a developer’s productivity more than poor configuration management. Even if it’s simple, it needs to be put in place.
How much time have we sometimes lost because the build broke, or because we wanted to roll back the code and couldn’t?
It’s not just about using a code repository (I’m almost embarrassed to write this, but some people work without one); you also need to establish some basic procedures for how a team of several people should use it.
Configuration management is a solved problem. There’s no need to innovate here; just spend a little time online learning about good practices.
#5 Create some documentation
Yes, this is obvious, but is anyone in the organization making sure the project is closed with at least some basic documentation? I’m not talking only about the end-user guide for the client (if they require one), but also everything we need to document so we can quickly pick up the project again in the future.
I always insist on creating a design guide that explains any aspects of the design and architecture that aren’t self-evident, as well as a thorough deployment guide that ensures we can install and run the project in a new environment. This is extremely productive and generally takes only a few hours (very few compared with the duration of a project). That time can save far more effort months later when we take on the project again, while avoiding the frustration of reverse-engineering how things were done.
A project can’t be considered closed if the required documentation hasn’t been created. In fact, we should see whether it can be produced as the project progresses.
When quoting a project, include some hours for documentation. Allocating 5% of the time to this work isn’t excessive.
#6 Whenever possible, use an agile approach on projects
On most projects, we can put into practice the aspects of agile development that help us make progress productively. Since a project will be profitable if it’s priced properly and completed on time, we need to pay close attention to anything that saves working hours.
In particular, showing the client our progress regularly (early deliveries) has a multiplying effect on project productivity and profitability, because the client can correct and steer anything we’ve misunderstood or any requirements we haven’t captured thoroughly enough.
Making corrections along the way is much more effective than correcting things at the end of the project, when the ball has probably grown too large and expensive to change.
Nothing new under the sun—just follow good practices.
#7 One project per person
This is essential, and I know it’s very difficult to achieve in companies. Having people work on several things at once is a bad practice. A developer needs a certain calm of mind to do their job well.
In any activity or kind of work, switching contexts comes at a cost in time and effort. In other words, if we have three projects underway and each one takes X hours, doing them all at once won’t take three times X; it will take considerably longer than if we did them sequentially.
As I said, this is very difficult to achieve in a company, but we should try to move in that direction.
#8 We need the right resources to carry out projects
Yes, I know, this is obvious—but can we really say that every company makes sure developers have the right resources?
The problem is that people don’t see the impact that lacking a good workstation has on a project’s final result. Having a good PC, the right hardware and licenses, and a comfortable, quiet environment, etc., means that things ultimately get done in less time (= profitability, which is the point of delivering projects).
There are many more considerations to take into account when creating an environment where projects can be delivered on time and with quality. We also need to be pragmatic: if we can’t fully achieve all the points I’ve described from one to eight, we should at least keep them in mind and bring the organization as close to them as possible.
To developers: wouldn’t we work much better this way? To managers: wouldn’t projects be more profitable?