Eleven “Make or Break” Project Management Tips

February 23, 2009 | Author: PM Hut | Filed under: Project Management Best Practices

Eleven “Make or Break” Project Management Tips
By Jonathan S. Ross

Although project management has now become a “hot topic” over the past few years and countless programs are emerging from both established and fly-by-night institutions to teach core basics of the discipline, at the end of the day there is nothing particularly mysterious or proprietary about the process from a conceptual standpoint.

While the value of earning “certification” in the field is open to some debate, depending on the source of the credentials, project management, like many other skills, is often honed over time through experience, hopefully by minimizing mistakes that might otherwise prove costly. Many “soft skills” such as the ability to communicate effectively, deal with different (and sometimes difficult) personality types and to provide inspirational and decisive leadership intersect with the knowledge base of organizing tasks according to a rigorously defined process and seeing these through to completion.

My intent here is to provide a snapshot of eleven (11) key issues that need to be addressed to keep any type of project moving efficiently and productively forward, regardless of the industry. Before we dive into these, it is instructive to discuss project lifecycle, and the logical stages / phases / gates (the choice of terminology is less important than simply acknowledging these exist!) which tie into objectives which should be derived from the project’s goals.

Because of my work in both traditional and digital entertainment in production-oriented, creative environments, I find it helpful to generally use a 5-stage framework, with associated high-level goals and milestones, along with corresponding written deliverables, which clearly signal the kick-off and closure (via written sign-offs from the client, whether internal or external) of each phase. The system is designed to ensure a smooth process flow and if properly implemented, prevents a project from de-railing due to misunderstandings or insufficient planning and agreement on what the final product is.

The project phases that I find can generally be universally applied are:

Discovery: This is where key stakeholders set up the general parameters and scope of the engagement, perform background research, and set up the collaborative team infrastructure. Finalizing a Project Charter should be one of the key objectives of this phase. A Project Charter should as a general rule contain a description of the project; statement of business objectives and success criteria; list of stakeholders by role and responsibility; vision statement; explanation of project scope; articulation of assumptions and dependencies; discussion of constraints; listing of project milestones (which may include delivery dates of key deliverables); evaluation of business risks; list of resources that will be made available (this includes human and financial capital, hardware, software, etc.); and approvals (who has authority to make “go/no go” decisions).
Definition: Once the Project Charter is established, along with the general scope, it is necessary to clearly articulate the business case behind a project’s raison d’être, a step which I find is sometimes overlooked during interactive technology engagements. People become overly excited by the whiz-bang factor and forget why they are creating a solution in the first place. As such, a critical written deliverable that needs to come out of this phase is a Business Requirements Document. Among the generally agreed to contents are a statement of the project’s purpose; background on the project; reason(s) for the project; alternative options considered; statement of assumptions; benefits of the project; known risk factors (critical for risk management purposes!); project costs and budget; and initial project plan (schedule); and recommendation. I personally feel that it can also be important to include an overview of the targeted market segments that the project is addressing as well as high-level discussion of the revenue model, if applicable.
Design: Having established what we want to create and why, there is often quite a bit of creative latitude involved in the “how” part of the equation. For all the talk that “form follows function” (in an ideal world), this needs to be carefully considered and it is essential that all decision-makers agree on the blueprints. Consequently, I advocate the creation of both Functional Specifications and Technical Specifications documents; while some may choose to combine these documents, I personally feel that before any technical decisions are made in support of the project, the functionality must be locked down, because technology should support desired functionality, which in term is driven by business decisions, and not the reverse!
Development (Production): This is the true “nuts-and-bolts” portion of a project, where the implementation team actually assembles the product according to specifications. During this phase, it is especially important for the project manager to produce regular status reports and track task progress, completion and interdependencies to prevent slippage in the schedule which in turn may impact the budget and profitability.
Deployment: This final phase involves the quality assurance testing (both internal and external, with records kept of problems found and the steps taken to resolve them, as well as confirmation that solutions were found) of the product to ensure that it conforms to specifications and is bug-free, as well as the product launch, which in some instances may necessitate hand-off to another department, such as marketing. Proper closure procedures should be maintained, including sign-off on all phases of testing and acceptance of the final product.

Even if a project manager is well-trained and methodical, and utilizes the phased approach, there are still a variety of factors which can sow discord and confusion, so here is a checklist of tips to hopefully mitigate problems. Ignore these at your peril!

Teams must have clear and delineated lines of communication: This may seem obvious at first glance, and is easier to implement in very hierarchical (i.e. corporate or military) environments, but is essential to establish early on. The Project Manager needs to establish both authority and respect from the internal team and must avoid the pitfalls of micro-managing affairs best handled by department heads or those in supervisory roles on the project team. It is also important that the client (in the case of an external project) be aware of the protocol for contacting the team, to whom specific information should be directed, and what is and is not acceptable. It is extremely important that the client designate a “project manager” of their own to serve as the point person responsible for the engagement!
Align all stakeholders with the mission and constantly check the alignment: This is best accomplished during the Discovery Phase and should be spelled out in the Project Charter (you do have one, right?). If you skipped this step, and you are knee deep in the project already, you should not necessarily despair; it is never too late to make sure that everyone involved is briefed on the reasons why the project is being pursued, what’s at stake, etc.
You must adopt a quantifiable phased approach to control scope, manage change and provide milestone markers: As established previously, a project without milestones and gateways is likely to devolve into Brownian motion or a boondoggle rather quickly, as one hand does not know what the other is doing. Different project management methodologies have different terms and recommended numbers of phases, but at their core, they all recognize and acknowledge the fact that if you cannot qualify and quantify something, you are in a world of hurt. Change management is often the subject of white papers and studies due to its crucial nature (stay tuned for our take on the subject in a future white paper) but is to be understood as the mutually agreed process by which proposed changes in project scope, functionality, mandate, purpose, etc. are handled. Who makes the decision to accept or reject changes? How is this documented? How is it paid for? Beware the dreaded “scope creep” in which the parameters of the project change, affecting budget (and usually schedule), yet the client still expects the cost to remain the same. If it does (because of poor project definition), it will most certainly impact your profitability.
Schedule should drive budget, and never the reverse: This is a mistake that is all too commonly made; the project manager is told, “Look, we’ve got X dollars to spend on this, and we need it by this date.” So the project manager tries to back into the date and starts making unrealistic resource allocations with little regard to actual capabilities (human or otherwise) and the impact on the project’s budget. Instead of engaging in this practice, it is best to approach the project as neutrally as possible, developing a preliminary schedule that reasonably accommodates the project’s scope, and then address the ensuing budgetary requirements. If it becomes necessary to “back into a number,” at least you will have an understanding of how and where costs must be reduced and timeframes compressed, or you will be better armed to explain to the client where reality and fantasy depart ways.
Progress should be measured against milestones agreed to in advance: If you adopt the phased project approach with its natural ebb and flows, this is easy to do. By securing approvals and sign-offs, you can avoid “back-flow” or “blow-back,” where stakeholders reconsider decisions previously made (i.e. change their minds) and expect the project to absorb these new realities with no impact on cost or schedule.
How you react to challenges and obstacles sets the tone for the engagement: As the project manager (PM), you are in a position of leadership and authority, and you must act this way at all times. There is a difference by the way, between being a “leader” and a “manager,” and although the latter word is part of the job title, I firmly believe that the former is the role that the PM (especially at senior levels) should aspire to.
Encourage an environment where internal feedback is constant: I cannot overstate the importance of regularly holding project status meetings with team members, which do not have to be lengthy affairs, but should have very clear agendas which can be satisfied quickly. Also take the time to “survey the troops” and to check morale; if there are problems, it’s your job to identify them and find solutions. So do it.
Project manager may not be a subject matter expert (SME) but must grasp the fundamentals of the project: There is some debate on this matter, particularly within specific industry verticals, but ultimately, a SME may not make a good project manager, and a good project manager may not be an expert on the technical details of the project that he or she is overseeing. What is important is to understand when you are getting out of your depth, and to make an effort to educate yourself as much as possible on the particulars of the project in order to avoid problems caused or complicated by what would otherwise be non-issues.
Entropy happens – Deal with it: I’ve actually developed a creative business philosophy predicated on this matter, but such self-referential comments aside, human endeavor and nature itself is filled with a tendency to devolve into what seems like chaos if left unchecked. No matter how perfectly formulated your project plan appears to be, reality will intrude, and as the saying goes, “No plan ever survives contact with the enemy.” This doesn’t mean that you shouldn’t plan, but your plans must be flexible, malleable, and ultimately adaptable to the truth of the moment now, not what it was then.
Regular Status Reports reduce the likelihood of surprises: If you have read Tip #7, this will be self-evident. Keep a written log or journal of all meetings, phone calls and email and make sure that all stakeholders are regularly updated on progress, any setbacks, or any potential new risk factors or things that need to be monitored to prevent possible schedule slippage or cost overruns.
Occasionally projects fail – What lessons can be learned? Nobody who has been doing anything for any length of time has a perfect record, especially if you count practice sessions. “To err is human” and you can bet that you, other members of the project team, or the client will make mistakes or miscalculations in judgment that may set a project back, or possibly even lead to its failure. What is vitally important in these instances is that after the emotion of the occurrence has passed, you hold a project debriefing or “post-mortem” to determine what went wrong, why it did, what (if anything) might have been done to prevent it, and whether changes in your approach or process might be considered to avoid a repeat in the future.

If you’d like to learn more about how Black Rock Consulting can potentially assist you with your project, please do not hesitate to call us at 310.598.6161 or visit us online at www.blackrockconsult.com.

If you would like to subscribe to our monthly e-newsletter, “Tao of the Zentropist,” please send an email to subscribenewsletter@blackrockconsult.com.

Our official and regularly updated blog is found at http://zentropist.wordpress.com.

Share this article:

This entry was posted on Monday, February 23rd, 2009 and is filed under Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Portfolio Management Process - The Process for the Process

The Role and Significance of an Interior Design Project Manager in Commercial Construction

Approaches to Leadership

Point of Total Assumption (PTA)

Project Management Foundations - Using Progressive Elaboration

Avoid Communication Breakdowns - Listen to Your Team

The Ineffective Executive

How to Deliver More Than Just a Good Project

Savvy Organizations are Developing Leadership Talent with Special Projects

Balancing Project Management and Project Administration

Eleven “Make or Break” Project Management Tips

feel free to leave a comment