A software project led by sales managers and their priorities. Sales managers don’t consider themselves a part of software development, but they practice a customer-provider relationship with software/engineering development team.
Many companies consider resource and development (R&D) a cost rather than an investment. Therefore, when managers determine that there is a new set of requirements within the organization and/or with their customers, the next obvious step is hiring new employees - software guys and girls - to fill the gap in order to develop a new project.
Usually the new project is estimated by sales managers, and this defines what human resources are required for the new project to develop.
Above description ends up with the following well known issues:
- Project cost and timings are estimated to invest notabily less in resource and development and production processes in favor of more cost and effort in commercial and marketing tasks.
- Hiring process is broken from the scratch, since global project requirements and decision flow done by sales managers are based on wrong assumptions because of technology ignorance, ending in hiring wrong professional profiles in terms of skillset and experience.
- Professionals cannot do their job right because of wrong resources and timing estimations.
- Project deadline is prioritized over finishing the project. All processes involved during a software development are artifically stretched.
- Real-time, high-level decisions are made by sales managers which, obviously, lack technical knowledge and they do them based on cost: the lesser is the cost, the more interesting is the decision. Or, at the end of the day, they cannot correctly evaluate which is the best decision based on both cost and quality.
- Any project role excepting sales managers are replaceable: any bad result during development will be because of technicians, and if some requirement or project delivery is not done in time, even when the project was broken from its beginning, since sales managers are higher in company’s hierarchy, they will fire techinicians instead of trying to fix or assume their responsibility in project failures.
- Bad management ends in a negative work environment. Everyone works with fear about what sales manager expects from them because project requirements are not a consensus: sales managers will be changing requirement details in a daily basis. What can be a priority on morning can be pointless in minutes.
While this document does not try to be a software project management guide, in general terms there are some points that can be discussed to avoid related problems with sales-driven development anti-pattern:
- Implementing horizontal project management is a good idea: hierarchical organizations are focused on who has the powers in the company instead of being focused on what to do in the company. Obviously, every professional will own a skillset on different knowledge fields, but this does not definitively mean that a mission within a company is more important than others. Every professional can have an high impact on project success or failure. Define roles instead of hierarchies.
- Avoid a customer-provider relationship between any role within the company. Everyone is important in an organization. Get involved in company’s projects as a permanent role, participate in meetings, invite relevant roles when doing critical decisions.
- Involve technicians in project planning and analysis meetings. Discuss with them what could be the best solution in terms of cost and quality.
- Define what communication channels will be open during project development, what to do if something goes wrong, project conventions. Good and effective communication within an organization is a critical requirement for successful projects.
- Focus on balancing timings, cost and quality.
- Define clear timing deadlines. Avoid real-time estimations and prioritization.
- Deal with project impediments as soon as they occur.
- Do not promise to customers what you have not discussed with technicians before.
Did you find some problem on this design pattern, or do you want to improve it?
Go to our GitHub repository and open an issue, and let's talk about it!
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License