The Perfect Interactive Project

Ah the perfect project. One can dream right?  What would all the players in a perfect project be like?

The Client.

They would be excited about their interactive project, and they’d be somewhere in the middle of micro-managing and laissez faire. The Client would give you enough latitude to make decisions, but would stay out of the way and not interfere in areas that are clearly your expertise. You would always be able to reach them for approvals and reviews at which time they would give you their undivided attention (especially from iPhones, laptops and blackberries) in meetings. When you needed to negotiate scope and impact on budget with them they would be tough but fair, and would concede to your wisdom where it made sense. They would not be overly upset or dramatic if scope or timing had to be changed to match reality.

Partner Vendors

In a perfect project, vendors would be helpful and would insist on going above and beyond the call of duty to satisfy you and your client’s needs. They would accept changes in timing and scope with good humor and would rarely push back or be upset by these commonplace occurrences. They would be okay operating in the background and would not have major egos or seek to win battles for control. Roles and responsibilities would be clear and defined and in any areas where they weren’t they would defer to your knowledge and leadership in the engagement. Change requests would rarely require additional funds as they would have already accounted for contingency in their planning. All their contributions whether it be coding or creative work would be well documented and would have defensible justification due to diligent note-keeping and management of conversations throughout the project. They could always be counted on to support you during the project lifecycle in order to best manage the client.

IT and tech teams

These groups would be fine being brought to the table later than they would prefer and would be quick to solve problems with creative ideas and collaboration. They would have a "can do" attitude and would be sensitive to the business and delivery team’s needs and overall pressure to deliver on time and on budget.

Internal Delivery Team

This team would be coherent and all members would work and communicate well with each other – even if you were unavailable for parts of the project, they would manage to get things done on time and per specification because they respect each other. They would work with you to review and revise the project plan to match the right solutions and they would make sure your budgets were managed/maintained through close scrutiny of their own tasks relative to the overall project plan. Creative folks would bring the same high level of energy to each and every project no matter the contents or direction from the client – their work would surprise and delight the client with its innovation/clarity.

Account Team

The account people would work closely with the project manager (you) and would be supportive whenever occasional bad news had to be delivered to the client. They would always defend you and the delivery team first and would make sure that the Client understood all delivery issues fully so they would understand root causes and be able to assist in decision making process. They would not shy away from tough discussions – but rather be quite adept at negotiation without upsetting anyone to a dangerous degree. They’d be able to manage troubles with a sense of humor and to the delight of all stakeholders involved. They would elevate their own company and company’s delivery team’s needs over their own and would work to keep the client as happy as possible under all project circumstances. They would actively contribute to the project by reviewing project documentation and confirming it matches up with client expectations from the sales cycle – any discrepancies would be clearly communicated to all involved to determine any areas that required fixing.

Sponsors / Bosses

These folks would push you to succeed and expect you to work hard, but would go to bat for you in the event that some project constituent was trying to push you around.  They would treat you as if you were innocent unless proven guilty and even if you ended being guilty they would be somewhat gentle with you as they valued your contributions.  They would be concerned with the bottom line, but more concerned with you and your delivery team, since people matter more than profits alone.  They would be interested in projects and would work to keep themselves informed as to project status without the need for arduous status updates.

The PM (you)

You’d have enough time in the day to coordinate your team and the clients/partners. You would via technology and communication methods be able to keep all stakeholders up to speed without countless meetings.  The Client would always feel comfortable to be able to be honest and frank with you and you would be authorized to make decisions for your company in order to deal with day to day adjustments.  You would feel confident you could hold your own resources to timelines and deliverables as you would have required authority from your company to compel them to get things done on time and on budget.  You would have any and all resources you needed without interruption and when you had them you would have their undivided attention.  If you happened to need them less or more based on scope it wouldn’t be a problem for enterprise resource planners.

Life would be absolutely great.  But of course this simply isn’t the way life is – and we will continue writing on the topic of interactive project management and how we can keep getting better at delivering the very best for our companies, clients and all involved.

7 Tips on How to make better time/scope estimates for your Interactive Project Tasks

When you are an interactive project manager you are often called to assist in estimating the effort required to bring a project to market.  Either you need to do this on your own in areas you have experience in, or you must ask team members and specialists to provide you with estimates.

This is not an easy job – and if done incorrectly could mean lost profitability or overpricing, both of which can be damaging in their own right.  So what can be done to improve estimates?

1. Ask for ranges? optimistic/pessimistic/realistic
Ask your subject matter experts to provide you with estimates of their work hours to complete the task.  But don’t ask them to only provide a single estimate.  Ask them for 3.  What is their optimistic guess if they find a few shortcuts or otherwise have no other distractions?  Ask them for a pessimistic estimate; what happens if they get hit with some foreseeable setbacks like needing to do research or get interrupted? And then after that ask them to provide what they think will most realistically happen given what they know.  What their truest hunch of what will happen is.

2. Do a WBS – break it into chunks
A work breakdown structure is an incredibly useful tool.  It revolves around taking your project and breaking it into all of its major tasks.  From here you take the major tasks and bust them out into subtasks, and in those subtasks you break them out further into the sub-sub tasks involved there.  Once you’ve really broken down the project into smallest units that a single person could do – you can label the whole diagram/hierarchy and seek estimates.  There are a few work breakdown structure tools out there you can try (google around) – but doing this on sticky notes or recipe cards can work too to visualize your project’s work units (especially if it is a big project).

3.In a rush/pinch provide estimates with a margin of error (for instance plus  or minus 10%)
Sometimes you simply don’t have enough time to get all the information you’d like from all parties.  In these cases it is prudent to work through educated guesses, and old projects and ask for quick 5-10 minutes of advice from your team members and cobble this together.  It isn’t *WRONG*, because the wrongness is built in – you are sharing the risks of the inaccuracy with your customer (it is a great way to get things done when you have little or no time to operate and a great way to share the risks of inaccuracy upfront with partners/clients)

4. Have more than one opinion on your figures (not just the same developer providing all figures)
Don’t always trust your first estimates (get second opinions!) – especially from people you don’t know that well.  Get a few cross-checks with other resources and if possible, people you know well.  If estimates have large variances from person to person do a bit more digging to find out why – is it a difference in experience, is it because one of your estimates was badly flawed?  Don’t blindly trust that your estimates are always 100% valid on first draft.

5.Get to know how your resources guess
Does Tom always guess high and Stacy always guesses too few hours?  Make sure you adjust slightly for known biases

6. Do better detail work on your requirements
Don’t blame the entire estimation process/results on your production staff/resources.  It is up to you as PM to define things well.  If you have a poor brief, or bad detail and your plan is full of holes and subject to interpretation – your estimates will be BAD.  Work on your briefs – get clarification from stakeholders to make your brief coherent.  And barring clarity, at least convey any and all assumptions you and your resource team made in order to package up your estimates (this is a good way to manage YOUR risks).

7. CLOSE THE LOOP
Review your actuals vs estimates when the project is complete.  This is a classic mistake: not learning from your projects.  If you track you and your resources’ time in a time tracker of some sort – go back and see what the actual time spent was relative to the initial estimates.  What variance is there?  How far off were people?  Why was this?  What can you learn from this?  What are people’s biases or tendencies?  If you’re not learning, you’re going to fall into the same traps over and over.

With a little practice you will improve greatly and estimating will seem a whole lot more natural.  How do you handle project estimation for the projects you work on?

Are late interactive project changes eating your budget / profit?

The project was doing fine a few weeks ago, but that was then – this is now.  Ever since then its been one little change after the other.  Nothing really big – but the client’s asked for this little add on, and that little bit.  Some of them were super easy and some weren’t.  Now these new bits and pieces are becoming interrelated and you’ve lost track of which relate to which and costs are mounting and you’re wondering if you’re going to maybe barely break even on your project…

This isn’t that uncommon.  It happens on big and small projects.  It’s that dreaded “scope creep”.  The gradual (and sometimes not so gradual) increase in work that occurs, usually while budget and timing aren’t changing.  The PMI (Project Management Institute) has some best practice techniques you can apply to help you avoid these situations in the first place.

Some of the concepts you should be familiar with are :

• The Project Baseline
• A Formal Change Request Process (including a change request form/template)

Your baseline is the agreed upon project scope (all the elements/features you are agreeing to deliver), the timing (schedule and milestones) and the terms overall for the project.  It defines the agreed upon state of what the end result of the project is to be.  This is CRITICAL if you want to be able to manage change later.  If you never FORMALLY review/agree/sign this – then who is to say that you didn’t agree to all those requests late in the project cycle?  It can become an ugly “he said” “she said” fact-finding mission to see if maybe someone on your sales or project team inadvertently promised something you weren’t aware of, or maybe the client is trying to pull a fast one on you, or they simply didn’t understand what you meant when you outlined what you’d be delivering.  It can be a relationship killer to go through a messy scope renegotiation late in the project.  Identify what you will be delivering and when.

Go through a Change Management process in advance – whereby you declare how you will handle changes to agreed upon scope later in the cycle.  Identify how this will be documented, how you will identify any additional time/cost related with such requested changes and how you will seek their approval/authorization before altering the project’s original baseline. Not all change requests will necessarily be billable – changes can originate from defects, business environment changes, or client requests.  But at least with a formal process in place you identify yourself as a professional and you take back control of the rate of allowed change to the project (HIGHLY desirable).

This ultimately protects YOU and makes sure that the Client is clear on what they are getting.  And potentially could save you a relationship in the long run (not to mention profitability). 

In future posts look for more on change management, document ideas/templates, and managing client expectations.

What documents do you use to control your Interactive Projects?

The standard documents are of course the following:

• The Contract (service contract and/or proposal)
• Specifications/requirements documents
• Project Plan
• Schedule (Gantt and/or Spreadsheet)
• Status Reports
• Change Requests
• Copy Decks
• Wireframes

But are there others that PM’s swear by out there?  What is the collection of documents you use?  Any uniques departures from the norm that you employ? Anything you’d like to share?

Since I am endeavoring to make this a Best Practices hub for Interactive Project Management I will centralize this debate and related information for others to share/benefit from so please share your ideas in the comments below!

How do you get into Interactive Project Management?

I recently received a few email questions on what it takes to get into the field of Interactive Project Management.  My advice, if you are in high school/university/college and are interested in being a project manager for an interactive production company (examples: agency, production house, web developers, marketing company or communications department) is to tackle it head on with a multi-faceted approach:

School – college or university can be good as long as you can find courses specific enough to directly help you out. I am not against a rich classical education to broaden horizons – but specific practical training is REALLY good for starting PM’s. You should be focusing on communications (mediation, written, oral & presentation skills, how to communicate good and bad news effectively), technology (networking, web technologies), business (marketing, business administration, some accounting) and specific software (Adobe products, dev environments).

Associations and Community – PMI is one of the really good resources for you. There are local chapters all over the place. Track yours down today and attend meetings or volunteer on their board – often these associations have their fingers on the pulse of local workshops and training that is PMI accredited as well. The PMP designation is much respected (I’ve got mine!) and is a great place to monitor the latest in best practice project management thinking – I can’t recommend it enough. In future posts I will be going on and on about PMI so stay tuned.

Experience – get into a shop as an intern (paid or not) and prove your worth if you can’t immediately get hired in a PM role. Be a contributor. Have a positive attitude. I’ve hired interns on as full timers before when they demonstrate drive, talent and a good attitude towards constructive criticism.

Projects – get into the thick of things as fast and often as you can stand (especially big or complex projects can knock the stuffing out of you, requiring some rest/rebound periods). The best way to become a superstar project manager is to have a lot of frames or reference from other projects. You’ll find your best modes of operating and have solutions from other projects that you bring to bear on your current situations.

Remember, the best Interactive PM’s:

• Are well-versed in technological terminology
• Can handle themselves in tense moments where information overload is common
• Have enough experience to know their way around technical project conference calls and meetings – knowing when to lead and when to ask questions
• Know how to talk to developers or designers in their own language
• Are generalists, but know a few production things so well you could actually step into a production role (this is consequently the best way to protect yourself in a recession economy too!)
• Are great communicators – knowing when to change modes – being a diplomat, leaders, or team-player when needed.
• Pay attention to detail – particularly detail related to timing, quality and project scope

We’ve Launched!

Pretty happy about that too.  This has been a dream of mine for some time now.  This place will evolve over time, but making the first step is the hardest of them all right?

Look forward to posts on new ideas, tips and interviews – should be a wild ride.

JP