Simplificar la Gerencia de Proyectos de TI

Recently I published a survey in many local distribution lists and groups -here in Colombia- about the challenges of the Colombian Software Development PM role. My findings didn’t surprise me at all. The two main concerns for the project managers -apart of those that you can find in any PM book, “like keep the project on track within the cost and time estimations“, “have a successful project” are explained below -let me know if those applies for other projects:

• Requirements definition is not accurate: Most of the times, clients do not know what they want or they just do not know it exactly -those inconsistencies or lags in their ideas become issues during the implementation or disillusions during the delivery.

• Implement and execute a formal software development methodology. PMI theory says that PM role can be done without dependency of the product execution -in this case software development. Probably the pure management can be done without technical knowledge but, in my humble opinion, the stakeholder expectations management and the team management will require it. I’m pretty sure it should be the same for other knowledge areas.

The Scope definition challenge

Software development is more sensible and can be deeply impacted by the “what if” changes. Software is not like a building, so clients cannot perceive the progress and so many times changes are included without that concern -I do my best every day to avoid this to happen, but as PM my main responsibility is not to avoid changes, is to keep the course of the ship.

Scope definition for SW development is specially complicated. That’s why now we can find many undergraduate and graduate programs that address that need of a good “need specification“. A new profession have been created Business Analyst or System Analyst/Designer -I really like those programs but for now do not have enough money to take one - if you want to learn more check the CMU or MIT programs.

Why scope definition and control are so complicated?

1. Client do not know what they want. This is the typical example of a company that do not evaluate their needs before starting a software development project. It could be probably because they believe innovation is related to implement a new software product. My suggestion, get enough time to research with the stakeholders and the sponsor, the expected results and try to associate them to the business needs.
2. Your company is sells whatever it takes to keep the client. Probably you were there, development teams complaining about the client services because they sell something that cannot be done with donating an organ -The Chicken and the Pig
3. You need a technical person gathering the requirements. I was reluctant to include this item because I believe -I really do- if a company does not include a teki guy during the requirements definition FOR A SOFTWARE PROJECT then there is no hope!

The key factor to simplify the scope management tasks is to have a change control system -a tracking system. If you cannot control the client requests, log, and plan them, you will have a lot of status calls, meetingitis, post-it-ingitis (i do not trust those guys with the monitor with fifty post-its with the PRIORITIES), or persons manually helping you -we call that here in Colombia chinomatic: chino can be translated -in Colombia- to guy, but in this context it means a person, that is not officially in charge of, but is more like an an assistant; and matic is an ironic use of the automatic word, obviously because it is manual procedure that the “chino” will execute.

The development methodology

There are hundreds of methodologies for software development. I cannot even use this Blog to discuss them, however there are some elements that you have in consideration before start your project under any given methodology:

1. You need time to do what you have to do. Today software projects seems to have the “agile pain“. Agile doesn’t mean fast, it means agile!!! -time cannot be reduced, there is no relativity in software development. If you have a sponsor or senior management that reduce the time by only including developers then my recommendation is to set the expectations since the beginning and use more than one release for the software product, in order to reduce the pressure periodically -BTW do not address the simplest things before, the idea is to reduce the pressure, not to postpone it.
2. You should have the right team. This can be read as you do not need a team upgrade :-). It is possible to start a project -and even common for those projects that innovates a lot the development process through new frameworks or technologies- to have the need to evaluate the team to validate if the can handle the project. My personal opinion is, if you want to get respect and commitment from your team, be the example, train yourself and lead your team through those dark times. If you do not want to do it, the lead the request of getting a new team leader. -I love to change my hat to senior programmer / architect / developer / system designer / whatever and lead the team to the victory -almost all the times
3. Technology is out there. Many companies in the software development business, these days almost all of them related to Internet / Web based / Interactive Agencies, do not use or plan their infrastructure. Many of those companies do no understand the need to have real development environments for development, testing and even support to production environments. It is amazing but true how something so important that supports the team work and improves the performance. Methodology is not about documentation only, is also about infrastructure.
4. Innovation also means Investments. Almost all the methodologies talk about process innovation, maturity of the process, cycles of  verification, improvement, or any other term that can be linked to improve the overall quality of processes and products. But even implement simple methodologies will required an extra effort that WILL HAVE A COST. The thing is, by improving the process you reduce the risk and time of a project.
5. Pick one. Last but not least, pick one methodology, could be your own, could be a standard, could be something in a book that nobody except you read it. However, pick only one, and make it your own. Companies will mature their own process through the time, and will reduce costs of moving team members from one project to another by only implementing a formal process.