This post originally appeared on the Stuzo | Dachis Group site.

A well planned meeting at the onset of any project with an energized and inspiring project leader establishes confidence in your company’s ability to deliver. It also inspires the surrounding stakeholders as they engage in the project going forward. What starts as an initial perception and team confidence booster, drives through into the rest of the life-cycle of the project.

I wanted to start this post with those thoughts as they directly relate to the mindset you need to deliver an engaging client kickoff meeting. To put some context around the client kickoff meeting in regards to a digital project, this is most often the stage after a statement of work has been executed, project scope is finalized (depending on the project and type of company), team leaders have been designated, internal briefings and initial project plannings have been made at the organizational level.

This is sometimes the first impression and integration of the cross-company stakeholders as they proceed into the digital project (i.e. Brand -> Agency or Agency -> Vendor). This is your Project Team’s (led by the Project Manager) opportunity to present your project plan to the stakeholders outside of your organization. Client-facing, this usually marks the transition where day-to-day project items going forward transition from your company’s account manager or business development team member into the Project Manager’s hands. You have this opportunity to continue the process of building comradrie with your partner, set and manage expectations, risks, mutual responsibilities and follow ups that will lead to a successful project delivery. Use this time to show your clients how proper planning and internal preparation, along with your leadership abilities, allow everyone to leave this meeting empowered and with a clear vision to move forward together.

Depending on the type of project, there are different levels of scope or services that may be provided. For example, an iterative software development project may not have the project plan fully defined at the kickoff, whereas a planned social application for a particular campaign may have detailed scopes, wireframes, and a project plan readily available in a quicker turnaround time. That being said, there are multiple routes a kickoff meeting could go based on the stage of the scope, detailed project plan and production approach. However, there are many best practices you should pay attention to regardless of the type of project.

1. Prepare internally at your organization before meeting with the client.

This sounds like an obvious head-nodder and something that is always assumed. However, I point this out as tip #1 as the beginning of any successful requirement requires team buy-in (and time), corporate alignment, and dedication to deliver the end product. The client kickoff call is one of the first times this uniform front will be able to be presented . That being said, note that proper preparation and documentation for this meeting takes time, and while agency project initiation may be quick moving, do not rush to the client kickoff without following the internal alignment steps you set at your organization. This may include first an internal project briefing – where the final statement of work, project goals, account background, etc is presented to the entire project team, discussed, prioritized, and sets the wheels in motion for internal responsibilities and project planning. Do not let the client kickoff occur without aligning internally as a team. Sometimes business development, account, and project team members have very hectic daily duties, however, never let this be an excuse for the team members to skip internal project transition steps. It will show to the clients if you do.

2. Have a documented agenda and be prepared to lead.

Client’s join this call because they very much have an interest in the project (obviously). Without an agenda and project manager prepared to navigate the meeting, there will be good periods of crickets and a meeting which leads to uncertainty on the client-side. I advise building a templated meeting agenda based on the types of projects your company takes on. With this approach, through your internal project initiation phases, you can leverage the team’s collective knowledge and have a defined process to prepare the required items needed to lead an effective client kickoff meeting. This should be led by the project manager, however, still requires dedicated team support in the early stages as the project is in transition. Items on the agenda should include: welcome and introductions, project definition and assignment review, scope review, timeline and responsibility confirmation, assumptions and unknowns, answering open items and setting clear next steps.

Continue reading »

On April 21st, Amazon Web Services experienced a service interruption, disrupting servers for many large and prominent businesses. Among those who were affected included an abundance of social services and websites such as Foursquare, HootSuite and Reddit. At Stuzo, we leverage EC2 for some of our hosting services and experienced temporary issues with our server infrastructure, as the Amazon back up systems did not kick in. As a result, this affected client applications which were live on Facebook, corporate websites, and elsewhere on the web.

Many companies have multi-zone failovers and other disaster recovery plans. On the technical side, we had most of our clients back up and running within an hour of the Amazon outage by leveraging our backup and internal recovery plans.

What did we do to respond to the situation from a Social Business perspective?

PLAN: Firstly, it’s important when working with any technology that you need a disaster recovery plan. Technology does fail and will continue to fail. It’s how you are prepared internally for these emergencies and execute when it does occur which will make all the difference. We’ve seen hardware and software fail before and know the importance of having a chain of command, operations, and procedures in these situations. This is documented and communicated through internal collaboration tools such as a corporate wiki, server documentation, and readily accessible information for the appropriate team members on the web. Generally, this just boils down to good business practices and the current tools adopted by our organization enable plans to be developed and documented more effectively.

SIGNAL: Through our server monitoring systems and communications measures the appropriate team members were notified instantaneously at critical points through the outage. This began with server monitoring tools at the root issues level (sending emails, SMS, etc) and the signal transitioned all the way  to our account and executive teams through our collaboration tools and communication practices.

DECIDE & ACT: We had to make necessary and demanding decisions before the sun was up for many of our clients. Do we wait for EC2 to come back, only migrate particular environments, notify all users? With the preparation and communication we had the right people with the proper knowledge available and briefed to make the best decision for our clients. On our end, we made the critical decision to migrate all live client applications associated with the Amazon EC2 environment in a time frame scheduled with the team (who were already notified through the signal stage and had an understanding of common options, responsibilities, and steps through our planning).

COMMUNICATE: On the account side we communicated the timeline and demands to make the migration happen internally along with a communication strategy for each client. All engineers, project managers, account managers, and appropriate team members were fully briefed on the status and progress thus far by seeing the alerts, briefings, and communication streams on their mobile devices prior to arriving in the office. Each client application that was moved to the new environment was tested by our QA engineers. Notification plans were setup for clients to ensure they were aware of the situation, our response to it, and how we are proceeding to manage in the coming days. Most of these occurred through emails to the clients coupled with direct phone calls early in the morning to provide transparency and responsibilities moving forward.

Continue reading »

Projects are fun and project management is too. Many outsiders to project management looking in sometimes don’t realize the skills and management techniques a successful project manager employs to deliver a quality project. In this post, I am going to cover the aspect of risk and risk management during the life cycle of a project and how it can result in a better product, happier team, and satisfied client.

While each project does present its own set of challenges and opportunities, there are many common themes across interactive projects related to risk. Recognizing these commonalities and adopting project and account management practices to address them will help minimize the impact a potential risk may have on a project. Ultimately, it’s a project team’s overall goal to keep a project on time, on budget, and at a superior quality level that executes against the key objectives. If we can implement efficiencies to keep projects under time and under budget, that is always a plus. Recognizing risks and developing solution plans are great ways to ensure success measures are met and, often at times, exceeded.

How many of you have worked on a project where a new & innovative technical feature was being implemented for the first time? How about a project where the timeline was moving so fast, a delay in creative delivery could jeopardize the project? With the proliferation of web technologies, how about encountering a new web service, which presents implementation uncertainties? You are not alone, these are common risks identified during an interactive project.

Risk always exists in a project. Whether the project is being managed by a 20 year PMP certified veteran or a newly minted project manager, there will be risks in the project. A risk could be an employee concern, technical limitation, timing issue, or even a client-side unknown among many other reasons. Now, that we have that part out of the way and acknowledged that risk is always part of a project, how do we keep it from looming over our shoulders and catching us at an inopportune time?

Get to love risk early on in your project. I know this might sound crazy for those not in this role, but this helps you avoid bigger problems down the road. Risk assessment should be included as a step in the early stages of internal project preparation. This requires a very open and honest mind-set from the team members involved. It’s critical not to let over confidence get in the way of fully engaging in this part. As a project manager, providing the necessary openness and humility to complete this step will allow your project stakeholders around you to embrace a similar approach to addressing risk issues.

Talk about the risks. Doing so, will allow you to tap into the knowledge of your supporting team, which often times decreases the initial assumed magnitude of the identified risks off the bat. Through communicating you will also become comfortable with eloquently describing and documenting the risk. You will find support across your team and tap into subject matter experts that will make your life much easier. It’s recommended to leverage the best tools available for your organization to effectively participate in the communication stream on risks while still being engaging. Whether you use a tool to do so or open brainstorming along the way, it’s the initial acceptance and mentality that drives a successful risk management process.

Document the risk and ensure an owner is assigned. Now that you have understood and communicated the risk early on, you may feel a little uneasy as project managers are often already thinking of the project, requirements and deadlines ahead.  It’s ok. This feeling will pass. Developing a risk resolution / mitigation plan with an identified risk owner at this stage allows you to leverage your best assets who will be going through the journey with you – your project stakeholders. As added advantages to distributing ownership of the risks to the best suited, you also provide team and individual accountability measures, which over time build camaraderie, expertise, and respect in the workplace.

Finalize the assessment and develop solution scenarios. Understand the implications of each risk and prioritize based on this knowledge. Some risks may have a quick resolution plan, while others may require significant time investment. It’s important to understand the possible effects of a discovered risk in a quantifiable way. Could it take you dramatically over budget? Over time?  Require pulling additional resources? Will you need to modify the work back schedule and re-brief the client? Understanding the implications and quantifying will help prioritize and align the entire internal (and sometimes client-side) team for the next stages of the project. When involving the client-side, it helps support with managing expectations, building trust, and leads to a great working relationship. The involvement required, really depends on the risks being determined.

To support with the prioritization there are some common buckets risks can be placed in to help understand the possible severity level by weighing the risk impact and probability:

Continue reading »

There have been discussions among the Facebook Developer ecosystem the past few weeks regarding the possible deprecation of the Facebook Share button to make the “Like” action the primary share point across the web. With the recent announcement that FBML will no longer be supported, indeed, the FBML Share action is deprecated. However, developers still have access to register a relevant action in their applications using the “stream.share” method in the JS SDK available. Unofficial documentation on this feature is available here and is not documented by Facebook. In fact, when searching for official documentation on “Facebook Share”, the search redirects visitors to the Like button documentation.

The updates released on February 27^th, showcase a fundamental series of changes unveiled to the Like button, which marketers and brands should certainly be aware of and begin investigating the best integration points for these features. With these recent changes, there is obviously heavy overlap on the features provided by the Facebook Like and Share buttons.

While the psychology behind how and why users click these particular actions is creating debate over what option to use, signs indicate that because of the investment made and its ease of use, the “Like” button is on its way to be the prominent feature and recommended implementation route by Facebook. Today, users go through a mental decision tree when they see a piece of content they want to let their networks know they find valuable. Users have the option to Tweet, Facebook Share, Facebook Like, Email, StumbleUpon, etc. This decision usually happens so quickly and so often for active users, that most have a formed opinion on what distribution method to choose depending on the category or context of the content. Facebook is continuously working on implementing options for publishers and marketers of content, to attempt to make this decision easier and more ubiquitous.

Below is some additional information on the recent changes to the Like button:

September 9, 2010: Facebook unveils three new updates to the Like button. (1) Users can now like content from Facebook applications Canvas URLs. (2) The Like button can link back to particular Facebook pages. (3) A prominent counter (“box count”) can be displayed to showcase the sum of Likes a piece of content receives.

February 10, 2011: Facebook announces deprecation of FBML in favor of iframes. FBML documentation of the Share button is removed. Notably, developers now have the ability to implement the Like button directly on the landing page of tabs. This feature was always available in iframe development, but now can be loaded directly on the landing of a Facebook Page tab.

February 27, 2011: Facebook rolls out the latest version of the Like button. Previously, when user’s Liked an item, a small piece of the story would go back into a user’s wall under “Recent Activity.” This often was buried on the user’s page with a simple link back to the content. With the latest changes, now when a user clicks Like a full story is prominently published on their wall with a thumbnail image, story title, and body text. Also available is the option to “comment” after taking a Like action.

Visiting a Piece of Content on the Web:

Like provides the option to add a comment:

Seamless Sharing of the Like back into Facebook:

With the option of a comment:

Continue reading »