Software Production Management

To choose the right software is not a simple process, and to choose the right project management software is then an even more complicated process and decision. Below you will find few tips and proposed procedure to reduce the risk inherit to this decision.

Tip #1

To choose and implement a PM software tool is not the same of implementing a PM process. Many organizations try to implement a software tool expecting a nonexistent-unnatural process improvement. If you do not have a formal process, or even if your process is not working you have to stop thinking that automation will fix/improve/solve your problems. Automation should be used to reinforce a process and minimize the weaknesses.

Tip #2

Every software implementation process includes at least the following steps -of course every company has its own natural process. Public companies have also additional restriction and evaluation/validation processes that will extend the suggested process:

• Identify needs
• Define selection criteria
• Create a list of options
• Create the request for information
• Evaluate responses
• Reduce the list of options
• Ask for demonstrations or pilot programs
• Choose one

Tip #3

Try to isolate your needs by using the following dimensions to measure the products you are considering:

• Scale – how big the change will be?
  • Simple: are you going to organize your projects?
  • Personal: are you going to automate estimation and planning on you projects
  • Collaborative: are you going to support a team? are you going to share information? do you need to centralize team communications?
  • Enterprise: are you affecting the whole company? are you going to bill to your clients using your projects’ data? do you have virtual teams all around the globe?
• Management Paradigm – do you and your team follow a traditional or agile approach to project management?
• Process Maturity – how formal/strong is your process?
  • Chaotic: No evidence of documented processes or best practices
  • Active: Documented processes carried out, but not formalized
  • Efficient: Consistent discipline started
  • Responsive: Ubiquitous and measured
  • Business driven: Provides data and information to drive business decisions
• Implementation model – are you going to buy the product and support it by yourself? are you going to adopt the SaaS model?
• Budget -
  

Tip #4

Set your goals – do not expect to do everything better and to include any improvement during the first phase (or the initial implementation cycle). Prioritize to get faster results. Below you will find a list of possible goals that you could address with a PM software tool

• Improve project reporting and tracking
• Improve estimating and scheduling
• Reduce cost or speed process up by automating workflows
• Improve resource assignments
• Improve project communication
• Improve project team collaboration
• Improve overall project process

Every goal will impact different functional areas within an organization. You should plan your implementation to impact those areas and improve those process that will add the most value.

References:

• 7 Goals of PM Software @ Software Projects.org
  
• Software Selection @ SoftwareProjects.org
• Evolving the Maturity Level of Your Project Management Office @ CA

Last week I was participating of the “Jornada de Gerencia de Proyectos de TI” – IT project management conference. It was great. Probably in other countries it’s usual to have great congresses or events related to PM, but here in Colombia, even the PMI Colombian Chapter sucks -even the name is out of date. It is not about find great PMs here in Colombia, you can find PM Gurus as weel, but they fail on their limited sense of community, and it’s inability to set a decent conference or even as a non-profitable group.

ACIS, the Colombian Association of Systems Engineers -and other professionals around informatics- have been leading this conference for the last seven years. It is not the most popular event ever, but it is great. It was my first, hope not the last. I met a lot of PMs who work for big IT companies like IBM, HP and Dell. I listen experienced PMs about PM tactics and techniques, tips and how to deal with people – most of PMs and PM methodologies do not take care about people because it is competence of the PM to handle people to keep the project on its way. But, is it true? Should be the PM who handles all the “human” side of the project? Probably it is, because almost all the times, PMs are the bridge between the senior management (and their necessity of results), and the team (and their personal needs).

The bonus of this event was the unexpected visit and presentation of Tony Johnson, the CEO of Crosswind - He talked about Program Management, its difference with Project Management, but also, he talked about Agile and how PgM works Agile. I was shocked, to hear a guy who works helping people to get its PMI Certifications talking about Agile. Wow! The presentation took no more than 45 minutes, and I was amazed about Tony’s ability to link PMI and Agile -while most Agilist seems to feel offended with the PPM framework of the PMI.

BTW, I did my part too, doing a short presentation about how to choose the right PM software tool for your company/team/project.

Congrats to Martha Ardila, Beatriz Caicedo and the whole team behind the event. It was great.

At the beginning it was pure calm. Junior developers do not have to do a lot more than coding, and to be clear it is about coding something that probably someone else have been already designed. Those days when I started coding remind me when I was a kid at the school. I didn’t have a lot of responsibilities and of course, the life was easier than now.

Then I became senior programmer, and then architect, and then system designer (Oh Dear God). Why? It’s probable because it is a natural process to grow up and get experience, knowledge and, obviously because it also means.. most of the times… a salary raise. But then I noticed that my whole perspective about software development had been changed. At that point I wrote the first draft of the Pee Paradigm. Please take a minute to read and understand it – you can also leave a comment.

When you are a programmer and you have to pee, you can just leave your desk at any given moment with one or few problems pending to be solved. Some minutes later -depending on your personal needs of course- when you come back to your desk you can be sure that 99.99% of the times it will be the same set of problems -nothing have been changed. And to make it even better, it is possible that while your were doing “your stuff” you came up with a solution to those problems! Amazing!. In contrast, assume that you get additional responsibilities including management tasks and you have to “pee”. So it comes the time when you have to LEAVE YOUR DESK and even when you will have a small set of “pending things” to solve or do, you can be absolutely sure that once you come back you will have additional items. And maybe you can solve things during your “reduced personal time off” but it will be certain that instead of solving things you will remember additional stuff.

Few months ago, when I was Production Manager for a huge project for one of the most famous brands in the world, I used to received more than 250 emails every day. Can you believe it? It was a mess. Obviously it was a failure inside the communications plan but it was true. So I created few rules to colorize my emails assigning colors depending on the recipients list. Let’s do some simple maths to clarify the situation:

250 emails x 1.5 minute reading
= 375 minutes
= 6.25 hours.

At this point I didn’t send an email, make a call, o even received it. I didn’t went to bathroom or do anything else than open my email client.

Could you imagine somebody asking about an specific email like “did you checked the Fulano’s email about the X situation?” – while my reduced set of neurons tried to evaluate and solve the question, another even more reduced set of neurons where thinking something like “Ah? Blah? What are you talking about? Was my name at the beginning of the email content or as the email subject?”

Since then, I wrote the Pee Paradigm and decided not take drinks at the office. Also I feel really concerned about have to pee during my working hours