By Esteban Sánchez, Project Manager, Avionyx, 2009
Revised by Jose Arias, Project Manager Officer, Avionyx, 2024
Project Management
We all want to manage our projects to completion within budget and schedule and end up with happy employees, customers, and managers. But like most other aspects of software or other projects, we need to have a methodology that is based on tried and true principles in order to have any reasonable expectation of success. And there's nothing that can replace the experience gained from the pain and suffering of doing it wrong, possibly more than once. But why not leverage others' mistakes? There are numerous methodologies that have been founded on the experiences of others, including but not limited to:
PMBOK from PMI
PRINCE2
RUP from IBM
ICB from IPMA
Each of these methodologies is based on observation and selection of the best practices that have proven to be helpful in many projects over the course of time. All of them have different characteristics that make them appropriate under specific circumstances. For example, PMBOK is a very complete and comprehensive methodology that can be applied to any kind of project. It covers all aspects of a project from initiation to closure. Similarly, PRINCE2 is popular for its business case-based model, which describes the rationale and business justification for the project.
So which is the best methodology for my company?
Since most of these methodologies are generic in nature and are not tailored to specific applications such as software development, don't expect to find one that won't require a good bit of surgery to make it work for your company. One side effect of generic project management methodologies is that they are very bulky and developing a 200-page project management plan that no one will bother to read, much less use, is not going to help achieve your objectives, particularly if this is your first attempt at formalizing your project management process. It is much better to start small. You can always add detail later after the company has adapted to the methodology. On the other hand, you may have needs that are specific to your company procedures and culture that require additions to these generic methodologies. That's okay too. Remember, the idea is to make them work for you.
Find a methodology that fits your needs best and start from there, deleting what you don't need and adding what is missing (possibly from other methodologies or from your previous methodology). You may decide to start with a hybrid methodology. An example might be to take advantage of PMBOK's in-depth methodology as a starting point, and then adding components of PRINCE2, starting with Product Descriptions, Quality Reviews, and Work Packages then possibly adding more complex processes such as the Business Case, Exception Management, and Configuration Management, which may be particularly helpful for software development projects.
At this point, you should be able to determine if you are going in the right direction and after evaluating the results and gathering some buy-in from the stakeholders, consider adding elements like the Project Board, which will provide a robust oversight and support mechanism for your project. Once you have completed your revisions and have a final draft, the next step is to review it for conflicts, continuity, and completeness.
Project Phases usually depend on other phases and make little sense when isolated, so make sure you clearly define the inputs and outputs of each phase. (e.g., in the planning group of the PMI's PMBOK, the Schedule Development process needs inputs from the Activity Sequencing and Activity Duration Estimating processes, so these three processes need to coexist). Once you have a buy-in from all the stakeholders and have a released document, the final step is to get it adopted as a company practice, implement whatever tools are needed, train employees on usage and then start using it.
What happens at the project level?
Don't forget though that every project is different. Just as the generic methodologies can be cumbersome if forced to use them across the board, individual projects have different needs and can be managed with varying levels of overhead, so don't make your methodology so rigid that you can't customize it to some degree at the project level. Different projects have different needs for staffing, tools, and compliance with internal or customer requirements, so make sure your planning phase provides a mechanism to customize the project plan.