| To begin, let’s get one thing straight: there really isn’t one set of ‘best practices’ for project management. It’s like the one-size-fits-all approach - which usually means everybody gets a shoe-bite. Efficient project management is more about developing the requisite skill sets to design and implement project management practices, with a proper understanding of internal and external processes. A ‘best practice’ could be too much of a template, too much of doing something the same way because it worked once. |
| Having said that, there are clearly ways to get things done right; the important thing is to understand how flexible and adaptable those ways have to be, when moving from one project to another. What follows is more like a set of basic ground rules, setting up a reliable yet agile framework to ensure project delivery is on time, on target, within budget, and above expectations. |
| The following piece is a direct result of experience with many successful, and more importantly, some not so successful projects we have worked on for our clients, at Regalix. |
|
| Ready… Set… Hold On a Minute! |
| Before we hit the ‘go’ button on a project, it is crucial to define the owner of the project. The owner is the single point of interaction with the client - and this ‘client’ could be an internal business manager (or account manager or client services exec or some such), or an external customer. The project owner is responsible for the overall project plan. |
| The designated owner should have access to the Sale Boarding1 and Account Boarding2 documentation, and uses all of this information to come up with the Project Plan. |
|
| The Project Plan |
| The project plan is the overall blueprint for the project, and has the following components: |
- Milestones
Setting up milestones begins with understanding the different phases of the project, and breaking them into concrete deliverables. Typically key milestones could be finalizing requirements, wire frames, mocks & HTML (for UI projects), development, QA, data migration, hosting, go-live followed by complete documentation.
- Activities and Timelines
Every activity that is part of the project must have a start date, end date, estimated end date, a status tracker, estimate of hours required, actual hours consumed, a percentage of completion tracker, and space for comments from all relevant workers on the project.
- Resource Names
This component allows the project owner to identify and allocate available resources in the most efficient and cost-effective manner possible. Decisions to use in-house talent vs. “sourcing from the cloud” are taken here, keeping in view best possible output for the client.
- Project Plan Template
The project plan template puts all the components in perspective, and allows the project owner to quickly understand project status at a glance.
- Client Updates Template
This is a crucial component: clients like to see where the project is heading at all times, and may revise requirements/change specifications as necessary. The update process therefore, has to be made fast and easy, to allow quick response times on both sides. This particular aspect is discussed in greater detail later.
|
| Typical Milestones of a Project Plan |
| The following table serves to illustrate the typical milestones in a technology project plan: |
|
Non GUI |
With GUI |
| Requirements |
Yes |
Yes |
| Wireframes |
- |
Yes |
| Mocks |
- |
Yes |
| HTML |
- |
Yes |
| Development |
Yes |
Yes |
| QA |
Yes |
Yes |
| Data Migration |
Maybe |
Maybe |
| Hosting |
Maybe |
Maybe |
| Go-live |
Maybe |
Maybe |
| Documentation |
Maybe |
Maybe |
| Training |
Maybe |
Maybe |
|
| Sample Project Plan |
| Given below is a quick screenshot of a typical project plan, created in Google Docs: |
 |
| On a quick perusal of the example above, the following observations can be made: |
- The columns for Activity, Owner/Resource, Start Date, End Date and Status, are all crucial
- Changes in fields are obviously possible, but is advisable that one sticks to a standard template – else can become a bit confusing for different stakeholders involved
- Google Docs is an easily managed way of tracking project plans, but other means can be opted for as well. Google Docs provides some neat project management templates that can be used for adapted for one’s needs
|
| Zooming in on the Weekly Client Status Update |
| Providing clients a weekly snapshot of where the project is headed is a critical component of a project plan. The weekly status update that goes out to the client could include a summary of the following: |
- Key milestones achieved
This should be supported by a ‘show and tell’ of all assets created, including mocks, demo URLs, and more.
- Milestone lag
All the blocks and barriers to achieving stipulated milestones can be discussed here, with suggestions on how to remove them.
- Initiatives to get project plan on track
With large projects, things can change a lot during their course; so this component of the weekly update must include a section on keeping things on track to achieving desired objectives
- Key Learning
As the project team becomes more familiar with the client requirements, and the client becomes accustomed to the project team’s working style, several learnings can occur; the trick is spotting them and documenting them immediately, before the ‘a-ha’ experience becomes a ‘what-was-that-again’ head-scratcher.
- Key Next Steps
Here we are now, here’s where we have to get; this is what we need to do to get there. Simple.
- Update Support
The weekly client update should be supported by a tabular subset of the project plan, which can:
- Include status of key milestones
- One could exclude fields like estimated hours so clients see what they ought to right away
|
| A sample tabular subset could look like this: |
 |
| Before We Jump In.. |
Here’s a quick checklist:
- Is there is a clear owner of the project (between client and technology team)?
- Is there a single point of contact from the client’s side?
- Has the account boarding document (brief from Account Management/Client Services team) been read?
- Are the goals of the project clear?
- Has the Project Plan been created?
- Does the Project Plan have regular milestones that showcase progress
- Has the Project Plan been signed off with the client?
- Has the format for the weekly update template been set?
|
| End Notes |
| Key to good project management is good estimation – better the estimation for the different activities that comprise the plan, less likely the project plan will fail. Like in most things one gets better with practice. Keep a tab of recurring patterns (like design iterations are more numerous than planned, client always seems to take more time to react, etc), and plan better in the future. |
| As you work on project plans, evolve some standard procedures that can form the foundation to good project management. The crucial word here is ‘foundation’; the best practices used from there on should come more from a library of methods (project plan components, learnings, checklists) based on real experiences rather than just a theoretical document. The library should also live and breathe, growing with every successful project. |
| 1 Sales Boarding Document: At Regalix this is the brief that sales team fills; and passes to the account management team |
| 2 Account Boarding Document: A document that account management team fills with the client, gathering all requirements, setting goals, etc; this document is passed on to the deliver team |
Email us
1-888-REGALIX
