Project Management CRM Best Practices – Project Management Procedures

This is the continuation of a series of posts regarding the Project Management CRM best practices.

Today I will write about how to define a project management procedures.
After the workplan definition has been prepared (see my previous post about Workplan), the project management procedures can be defined.


To define project management procedures up front we need to outline the resources that will be used to manage the project. This will include sections on how the team will manage issues, scope change, risk, quality, communication, and so on. It is important to be able to manage the project rigorously and proactively and to ensure that the project team and all stakeholders have a common understanding of how the project will be managed. If common procedures have already been established for your organization, use them on your project. Once the project has been planned sufficiently we can manage the workplan and monitor the schedule and budget, execution of the work can begin. But be careful with things like "as soon the project is approved let go develop" this is completely wrong, we always need to create a nice and good technical design by the Microsoft best practice, with mock-ups, what bottoms should be shown, how the security model should be implement, etc. If you don't do this, what is going to happen? You will finish telling the client how we feel how they should proceed and them? You will redesign 10 times each process... so make yourself a favor and draw mock-ups to make the user understand what is going to get, this is a really, really important.

In theory, since you already have agreement on your project definition and since your workplan and project management procedures are in place, the only challenge is to execute your plans and processes correctly but because there`s no project ever goes as it was estimated and planned, the challenge is having the rigor and discipline needed to apply your project management skills correctly and proactively, detailed as possible, describing what is need in every single workflows, business flow, plugin, web service, etc. Review the workplan on a regular basis to determine how you are progressing in terms of schedule and budget. If your project is small, this may need to be meet 2 times per week, 30 minutes is enough to keep the track on the project and for bigger projects 1 per week with 1 or more hours. Identify all the tasks for the week after and chase the current week tasks and update the workplan to show they are finished. 
Determine whether there are any other activities that should be completed but have not been like a new plugin that wasn`t in plan. After the workplan has been updated, determine whether the project will be completed within the original effort, cost, and duration. If not, determine the critical paths and look for ways to accelerate these tasks to get you back on track or same times certain changes or tasks need to be pushed to other phase. Monitor the budget if we are working with fix price and in a case of time materials make sure the client have budget to cover the excess of work. Be sure that the amount of money your project has actually consumed and determine whether you`re actual spending is more than originally estimated based on the work that has been completed. Be proactive talk with your developers and predicted the amount of the remaining work and when will be completed to hit your original budget or else raise the risk with the client so you can exceed the initial budget.

Being proactive you will need to look for signs like:

• Variance in schedule and budget starts to get bigger, especially early in the project. There is a tendency to think you can make it up, but this is a warning. If the tendencies are not corrected quickly.
• You discover that activities you think have already been completed are still being worked on. For example, users are still working in test scripts and is taking longer than actually it should.
• You need to rely on overtime to hit the deadlines sprints especially in the begging on the project.
• Team morale starts to decline.
• Deliverable quality stars to deteriorate. For instance, users complain on workflows or plugins not working like calculations, emails, etc, javascripts giving errors on the load of the page, be sure the developers do they on test before put the solution in UAT.
• There`s rolls back need to be done