If you are like me, I took this to mean that the customer wanted potatoes. When the order came up, the customer replied, “Oh, I asked for the fruit cup.” Since overhearing the original order take place, I began to think about what exactly the customer asked for because I’m in the business of gathering requirements from clients so this was all too familiar to me.

Original Requirement: “I’d like to substitute the fruit cup for the potatoes.”

Now this requirement could have been interpreted two ways:

1. Customer wants fruit instead of the potatoes.
2. Customer wants potatoes instead of fruit.

The waiter had a 50/50 chance, in this case, to get the client’s expectations correct. However, the waiter (and I) assumed incorrectly. This could have been easily corrected by just repeating back to the customer, in the waiter’s own words, what the customer wanted: “You would like to have a side of potatoes?” The customer could have corrected the waiter during this point versus having to wait until the order was delivered to only find out it was wrong.

This can happen all too often in any industry, but we experience it a lot in the software development field. You may have seen the infamous comic strip of the “tree swing”, as shown below:

There’s always a small chance for error when acquiring and understanding requirements from clients. Hey, we’re all human, right? But you can help ensure you get them 99% right just by using the following three tips:

• Repeat the request using your own words. Try not to use technical terms. Clients can have a different definition than you or may not admit they don’t know what you mean.
• Draw a picture. A picture speaks a thousand words.
• Ask the question a different way and see if you get a different answer.

Remember, you never know when the client might want fruit and you give them potatoes.

When we last discussed this particular project at hand, I ran up against a predicament to deliver a solution that did not allow for the development of a fully-customized software solution due to time and budget restrictions. As a project manager, I needed to figure out how to deliver an end result that was considerate of both the client’s expectations and the project’s restraints. Because the budget was tight and the clock was ticking, I had to trust not only our research, but also my instincts, to finally select a third-party vendor that would satisfy the project requirements and deliver the right solution.

Choosing “The One”

If you recall during the discovery phase of the project, we had spent a good amount of time researching third-party sources, creating detailed documentation, and presenting options to our client. After we had narrowed our list of possible vendors from six to three, it had finally gotten to the point where an informed decision needed to be made in order to stay on schedule. There was only one that could be “the one”, so I had to bite the bullet and select a vendor.

I was able to find “the one” after disqualifying the other third-party candidates either due to lack of responsiveness or fulfillment of project requirements. After performing more research and creating more documentation, we presented the final choice to the client in a way in which we felt confident. Because the vendor we selected was an overseas company, we knew it was crucial to include in our research the differences between our company and the third party in regards to work ethic. Likewise, it was important for us to confirm this information with the third-party vendor to ensure there would be no surprises.

Fortunately, our research paid off, because not only was the client satisfied with the decision that was made, but we were able to smoothly transition into the development phase. As a project manager, it is a great feat when the discovery phase can conclude on an optimistic note.

Beginning the Development Phase

Now that we had all the building blocks in place, I felt confident that we could proceed into the development phase of the project on the same positive note, irrespective of the known challenges and unforeseen obstacles. After all, proactively maintaining a positive attitude is a key step in instilling lasting confidence in each project stakeholder. However, as any project manager can come to expect, obstacles are bound to present themselves in every phase of a project.

So far the greatest obstacles I have encountered during the development phase are simply due to the fact that (1) the deadline is close, (2) the development team is far away, and (3) the software development approach is agile. To quickly and efficiently overcome these three obstacles, I have been depending on communication, accountability, and adaptability to see me through to the end.

. . .

Obstacles in the Development Phase

A Close Deadline

This project was not only tethered to a strict schedule, but it also had a hard launch date, which simply meant that a date had been selected in which the final product would go live. In other words, the project must be absolutely completed by a certain date – no ands, ifs, or buts allowed. Once we jumped into the development phase, there was no longer any room to make mistakes or ponder if we made the right decision. This hard launch date was approaching quickly and our team had work to do.

Anyone who has ever been involved with a group project knows that communication is the key to success. When the development phase of the project began, I knew that I would need to increase the communication between myself and the project team. We relied on daily email messages and phone conferences to discuss the status of the project and to ensure each deliverable was being met on time. Despite the physical distance, this method proved effective as long as it occurred frequently. Not only did the constant communication between the team and I allow us to identify and resolve problems quickly, but it also kept everyone proactively aware of the approaching deadline. When the hard launch date hits, I am sure we will be able to say that we met our deadline gracefully.

A Remote Team

When we made the decision select a third-party vendor to handle the development, we made sure that we identified the benefits and drawbacks involved with managing an overseas company. One of the greatest drawbacks should be obvious: the physical distance. Face-to-face communication is often an easier avenue to discuss and resolve issues, because both parties are able to see and understand the project’s physical documentation, collateral, and so forth. However, these conveniences were not readily available to the project team and we had to learn to work together remotely.

From my experiences as a project manager, it is important to claim ownership of managing all of the resources involved in a project. This should be an assumed responsibility, but sometimes it can get lost in the process and can therefore result in an unfortunate round of the “blame game”. Clients do not want to manage third-party vendors – they want a solution to their problem. The client understands that I am managing all of the third parties involved and that they do not have to worry about a single thing. By assuming accountability for this task, I become the primary contact for all communications related to the project and am therefore able to manage my remote team more effectively.

Despite the physical distance, my remote team and I were able to communicate and document issues that occurred during the development process by utilizing case management software. This software allowed me to assign each project requirement to a use case, which I was then able to view its progress to help me gauge if the deliverable was to meet its target completion date. Also, this software served as a great collaboration tool for us. I was able to ask questions to the developers and have them respond quickly and provide feedback, which definitely ensured that the project stayed on track all parties were held accountable for their tasks.

An Agile Approach

Software development can be approached in different ways, one of which is referred to as agile software development. The agile approach is an iterative and incremental methodology that relies on rapid releases and a collaborative environment to produce an end result in a timely and cost-effective manner. To put it simply, the agile approach does not require that all of the project requirements be defined before the design or development (or any other phase of the project) phase can begin. The phases of the project overlap and will be revisited several times throughout the project’s lifecycle. From a project manager’s perspective, this can be an overwhelming task when you are already managing a risky project that cannot compromise on time or cost.

I did what any good project manager would do: I adapted. I had no choice but to make do with the situation and approach it like any other software development project. The discovery phase is crucial to any project’s success, which meant that I did not neglect the necessary deliverables (use cases, wireframes, etc.) required to define the project requirements. The only difference is that not all the project requirements were defined during the discovery phase. Likewise, whenever the client wanted to change a requirement, I had to reiterate the fact that once development began, any new requirement would have to be included in the next release of the software. It was also important to consider each new requirement against the project’s timeline and budget; if it did not agree, then we both knew that it was not a “must have”, but more of a “nice to have” feature.

. . .

Part III: Ending the Development Phase

This project has been a welcoming challenge from the very beginning. I was given a project that was not only outside my comfort zone, but it was also one that carried high risk, a tight budget, and a strict schedule. I greatly look forward to seeing the launch of the final product and exceeding the client’s expectations that were set forth at the beginning. Likewise, I look forward to reflecting on the valuable lessons that this experience taught me as a project manager.

Stayed tuned for Part III of the series in which Crissy discusses how the project turned out, including if and how it met its target hard launch date without going over budget. She will also reflect on how she overcame the challenges of the project and the lessons she learned through this unique experience as a project manager.

Every project manager knows that one of the most important aspects of his or her role is to be able to communicate effectively and transparently to all those involved with a project. A project manager must not only be able to convey insightful and meaningful information to project stakeholders, but he or she must also be able to establish a consistent and timely vehicle for communication that can be consumed by all those involved in the project.

How can a project manager establish this vehicle for communication? The answer is simple: by creating and distributing a project status report. This piece of documentation allows project managers to communicate the progress of the project while managing expectations. To ensure that the project stakeholders do not get lost in the details of the status report, I greatly recommend keeping it simple by adhering to the best practices outlined below.

Best Practices for Creating a Status Report

For a status report to measure up to best practices standards, it must be clear and concise. Likewise, it must provide valuable information that clearly illustrates the current state of the project with respect to the project’s scope, schedule, financial position, and risk position.

Divide Sections by Task Type

I’ve found that in order to keep the status report simple and to ensure that it provides enough insight for the project team and sponsors, the project status report should only contain a few sections divided by task type. The types of tasks include completed tasks, current tasks, planned tasks, current issues and risks, and late tasks.

• Completed Tasks: Outline the tasks, deliverables, and milestones that were met during the reporting period.
• Current Tasks: Describe the work that is currently in progress. It is important here to identify work being completed by the project team, as well as information and deliverables that are needed for the project team to effectively begin the planned tasks.
• Planned Tasks: Describe the tasks that are to be completed in the subsequent reporting period according to the project schedule.
• Current Issues and Risks: Identify the issues and risks that affect the project’s scope, schedule, and cost.
• Late Tasks: Identify tasks that are late and include ownership of that task. It is important to acknowledge whether the project team is late or whether the delays are being introduced by factors beyond the control of the project team. The intent is not to place blame, but simply to provide sufficient information to escalate the issue for effective resolution.

Include the Right Amount of Detail

As a project manager, you need to determine the appropriate level of detail to include in the status report. The status report should provide enough detail to be valuable to the project team and stakeholders, but not too much detail that it becomes overwhelming to middle and upper management. Always be aware that the management team has many priorities and is typically impressed by reports that provide information on what is critical to the success of the project. I’ve learned through trial and error that the more efficient you are in presenting the status of the project, the better impression you make.

Align It with the Project Schedule

For a status report to be effective, it must be aligned with the project schedule. We construct our project schedule based on tasks that are no more than 40 hours. Using this rule to dictate task duration, we can make a general assumption that everyone on the project team should have at least one task per week that that should be completed. In addition, this rule of thumb for scheduling allows us to track tasks by resource, which allows us to gauge whether an individual resource is ahead or behind the project schedule. Using this scheduling philosophy, we can easily report the status of tasks that are completed, active, and planned based on the project schedule.

Most Importantly, Keep It Simple

I’ve found that a generally good length for a status report is 1 to 2 pages, ensuring that the highlights of the project are covered. Status reports that are too long will likely not be read completely by all those involved in the project, which will unfortunately waste your efforts. In other words, the key is to keep the status report simple so that all those involved with the project can quickly and easily understand its status.

Why do I aim for simplicity? It is understood that executives are typically on a time crunch and just want a snapshot of the status of the project. The project manager and team, however, usually demand much more detail to fully understand where the project stands. An effective status report should accommodate both of these needs.

To do so, a status report should incorporate an executive summary with a color coded dashboard to visually show the status of the project. Both features give executives a quick update at a glance. Likewise, the status report can easily transition into weekly status meetings with the project team so they have the necessary specifics to discuss the project, make changes, and plan for the next steps.

The Goal of the Status Report

Ultimately, the goal of the project status report is to keep everyone involved and on the same page. This allows the project to proceed as smoothly and efficiently as possible. As a project manager, you will want to make sure there is no confusion about the current status of the project. Likewise, you want to ensure that all of the issues and risks that affect the project’s scope, schedule, and cost are rightfully addressed.

My fifteen+ years of project management experience has taught me a great deal about being an effective and transparent communicator. A good project manager promotes communication by not only understanding his or her project stakeholders, but also by adhering to a proven and consistent methodology when it comes to creating and distributing project status reports. A great project manager, however, knows how to sift through the details to identify and communicate what is most important. In other words, a great project manager knows how to keep it simple.

Every project manager knows that with any project that falls outside his or her comfort zone, it induces a level of unavoidable risk. Some project managers thrive on this risk and are able to haphazardly proceed with flying colors. On the other hand, some project managers buckle under the pressure and are not able to deliver a sound solution to the client. There are some project managers, however, who are able to navigate through this risk and achieve a balance that allows them to understand, accept, and manage this risk.

As the senior project manager at Galvin, I identify with the latter pool of project managers. I do not mind the risk that comes with uncharted territory; it keeps me on my toes and pushes me to think critically and creatively in bigger and better ways. However, it is important for me to understand what it is exactly it is I am getting into before any decisions are made.

The Challenge

Most recently, I ran up against this unfortunate predicament: our client needed a solution in which the time and budget did not allow for us to be able to utilize the best of our internal resources to develop a fully-customized software solution. Thus began my challenge to discover how to deliver an end result that would be able to exceed the client’s expectations while being considerate of a strict timeline and budget. To ensure that I am leading the client down the right path, I rely on the following four tips, which have proven to be useful in such challenging situations.

Stay Positive and Confident

When faced with a project that forces you out of your comfort zone, it is especially important to remember to stay positive. The fear that stems from the unknown, especially in projects where it is hard to visualize the end result, is understandable. It is also natural to feel anxious in these fearful situations, but a project manager must be able to push all of this aside. Instead of catering to fear, the project manager needs to actively maintain a positive attitude that instills confidence in all the project stakeholders. If you believe it can be done, it will be done. Sometimes it is a matter of simply saying, “Yes, we will deliver the right solution.” Say it a few times and suddenly, the project seems easier to tackle.

Realign Client Expectations

Your first interaction with the client after the project has been signed off is absolutely critical. I always take this moment to realign the client’s expectations, especially in cases such as this where the risk is high, the budget is tight, and the schedule is strict. Although the client is dead-set on a certain solution, sometimes there are requirements that were not initially identified that need to be discussed. Likewise, sometimes there are requirements that need to be carefully reviewed to ensure that each one can be properly met. If I am up against requirements that just will not work, then this is the time in which I employ the art of compromise. From my experiences as a project manager, I believe that compromise is necessary in order to swim outside the box to find the buried treasure. Not only does it show the client that you understand what it is they need, but it also enforces the message that they are in good hands.

Research, Research, Research

A project of high-risk cannot be delivered successfully without doing a fair amount of research and development. To find a solution that would fit within the restricted budget and timeline, I needed to look beyond our internal resources and to third-party sources. Based on the client’s expectations and project requirements, I researched viable options and then was able to created informative documentation to present to the client. Not only did the presentation generate valuable feedback, but it allowed me to narrow my selection of 5 to 6 solutions down to 3 and 4. Although it does feel encouraging knowing that we are on track to finding “the one”, there is still that nagging feeling that I need to make the best decision, the one that will give the client a bigger bang for their buck. However, I remain positive that our understanding of the project’s requirements will allow us to make the most educated decision that will deliver a solution that generously exceeds the client’s expectations.

Keep Your Salesman Close

Last but not least, I make sure to keep my salesman – the one who approached the client with a solution in mind– as close as I can. As a project manager, it is important to do so for several reasons. If you cannot realign the expectations with the client during your first interaction, then it is time to call on your salesman to redefine the client’s expectations and project’s requirements. Likewise, if the solutions you have presented are not what the client wanted or expected, then it is necessary to call on that relationship between Sales and The Client to determine how to proceed. I trust that this relationship will encourage the client to compromise and accept a solution that I know will not only meet their needs, but I know that we can (and will) deliver.

The Next Step

Now that the client has narrowed the solutions down to 3 and 4, I am preparing to present a more detailed overview of these options to show how each one satisfies the project’s requirements. Because of the timeline and budget, soon I will need to go ahead and pull the trigger. In other words, I will need to make an informed decision to proceed with a third-party solution so we can begin the development process. Even though making this decision has proven difficult, I know that the worst is still not over; there is a timeline and budget that my team and I will need to be deeply considerate of until the very end.

Despite the fact that this particular project fell outside my comfort zone as a project manager, I welcomed the opportunity to learn and think more critically and creatively during the discovery process. Likewise, I appreciate the experience of this challenge, which I know will serve as valuable knowledge when similar projects fall under the umbrella of my management in the future. I have the utmost confidence that I am leading the client down the right path and that we will deliver the right solution on time and within budget, as promised.

Stayed tuned for Part II: The Challenges of the Development Process and Managing a Remote Team, in which Crissy discusses how “the one” solution was finally selected, how the team proceeded into the development phase, and how she handled the challenges of managing the project and its external resources, tight budget, and strict schedule.

Winston Wolf, Problem Sovler.

This past weekend I found myself getting caught up watching Quinten Tarantino’s 1994 classic gangster film Pulp Fiction. Of all of the great scenes in the movie, I’ve always been most fond of the, “The Bonnie Situation.” In case you don’t recall or haven’t seen the film, The Bonnie Situation is a short part in the film in which two characters, played by Samuel L. Jackson and John Travolta respectively, find themselves in a tight spot.

They are on the run and drive quickly to one of the character’s friend’s home. They arrive announced and park the car in the garage. The friend, played by Tarantino himself, tells them that his wife Bonnie will be home very shortly and that they have to have their problem solved and be gone before she gets home.  In search of someone to help solve the problem, a new character, played by Harvey Keitel, is introduced, Winston Wolf. Once called in, he quickly arrives and announces that, “I’m Winston Wolf, I solve problems.”

Over the course of the scene, Mr. Wolf introduces himself to the other three characters and is very careful to outline who each character is and how their role plays into the problem at hand. Along the way, he shows that he’s not afraid to ruffle a few feathers and that everyone has to listen to him in order to solve the problem by the deadline. He then evaluates all the factors that play into the solution of their problem. He very quickly prioritizes what needs to change with those factors, how those changes will take place, and what is needed to make them happen. He then clearly communicates this to the other characters in the scene. Of course, at the end of the scene, Mr. Wolf and the other characters have worked through all of the steps that he has laid out and the issue is resolved right before Bonnie arrives.

When I first watched this movie while I was in high school, I never realized exactly what Mr. Wolf was in the context of this scene. Now that I’ve worked in the professional world for a number of years, I realize that Winston Wolf isn’t just a problem solver, he’s a Project Manager. Think about it, he:

• Introduces himself
• Immediately identifies all stakeholders
• Evaluates all factors of the problem at hand
• Devises a plan for solving the problem
• Clearly communicates the plan
• Procures what is needed to make the plan happen
• Puts the solution in place step by step
• And wraps everything up making sure everyone is happy and that the requirements have been met in the end

We’ve recently just started a project with a local company who has a problem with a very solid deadline, but no defined solution. In that instance, we are their Winston Wolf. We’ve come in and identified the all key stakeholders, identified the problem at hand, all factors and resources needed for a solution, and are currently in the process of working through that solution with all involved.

While I know it won’t encompass everything that Galvin Technologies has to offer, I really wish we could start introducing ourselves with, “We are Galvin Technologies. We Solve Problems.” It is so simple, but means so much.

There seems to be a common problem in the Information Technology industry: it is a great challenge to deliver a web or software development project on time, on budget, and within scope. According to Advanced Project Portfolio Management and the PMO, only 16% of IT projects are able to achieve this status of official project success. We understand that a project must be managed well from beginning to end in order to go above and beyond a client’s expectations and to achieve this status of project success. In order to do this, we believe that you must set proper expectations, focus on project deliverables, communicate early and often, deliver within budget and timeline, and provide service-centered value.

Set Proper Expectations

Before you dive into any project headfirst, it is important to understand what exactly it is your client needs to achieve. After all, you would not build a house without first knowing how many rooms need to be built, where each room needs to sit, and so forth. A web or software development project is no different; it needs to have a detailed blueprint that outlines the end result at the very beginning. A project should not progress past its Discovery phase without completely understanding the end result and what steps will need to be taken to get there. Once it is determined how you will proceed from Point A to Point B, proper project expectations should be set that meet – but mostly exceed – the client’s needs. Likewise, a proper expectation should be realistic, uncompromising of requirements and deliverables, and courteous of a project’s timeline and budget.

Focus on Project Deliverables

Project expectations and deliverables are equally important and should be your focus of every project. When you focus your attention on the expectations of the project and its end result, it is much easier to understand how you will need to get from Point A to Point B. A project that lacks an end result in sight, however, is unlikely to be successful or survive the unexpected. Not only will focusing on the end result allow you to better understand the overall scope of the project and the tasks at hand, but it will also allow you to effectively manage these tasks and ensure that each one is proactively considerate of project scope and budget.

Communicate Early and Often

Communication is the key to exceeding a client’s expectations and delivering a successful end result. A project that lacks timely and routine communication faces the wrath of the unknown, which can be detrimental to the project’s timeline, budget, and end result. You should strive for consistent communication; this means scheduling a certain time and day every week to follow up with your client to discuss a project. This may include the discussion of the project’s status or any performance, testing, or development issues that may negatively impact the delivery of the project. By setting a specific block of time every week, communication allows you to effectively manage the project to ensure that 1) the project is on time, 2) the project is within budget, and 3) the project will deliver the expected end result.

Deliver within Budget and Timeline

To promote client satisfaction, you should aim to deliver an end result that not only saves his or hers time, but money as well. One way to ensure that a project is not exceeding its budget or timeline is to carefully manage change and unplanned activity. It is often said that in project management, the only constant is change. Therefore it is crucial to plan for these unforeseen circumstances during the discovery phase of the project. Change can be a budget and time killer, because it has the unfortunate potential to interrupt other projects and affect the availability of your resources. It is not an easy task to plan for the unknown, but it is extremely important to establish a budget and timeline that is robust, flexible, and accommodating to unplanned activity. This means determining the complexity of project deliverables, determining the greatest constraints (such as time, resources, et cetera), and then planning for these factors while being considerate of deadlines, budgets, and so forth.

Provide Service-Centered Value

At the heart of it all, a client’s expectations are indefinitely exceeded when you are able to provide service to them that not only satisfies, but surprises. We like to call this “Service Surprise”, which basically means that you strive to provide outstanding service that ends your client’s experience on a shockingly positive note. We want our clients to feel as though we are not only delivering an end result, but an end result that is coupled with service-centered value. Because every client is unique in his or her needs, the expectations we want to exceed will therefore be just as unique. To go above and beyond these needs, it is absolutely necessary to truly know your client and what it is they want to achieve. You should continue to manage the project beyond its delivery date by continuously thinking of ways that can provide more value to the client, such as analyzing the effectiveness of a user interface, revisiting a solution to determine if the workflow has improved processes, or keeping up-to-date with the latest technology threats and compliance standards.

We are able to go above and beyond our client’s expectations by abiding to our process and project management methodologies. Our process and project management methodologies ensure that we set proper expectations, focus on project deliverables, communicate early and often, and deliver within budget and timeline throughout the project’s lifecycle. Likewise, we distribute customer satisfaction surveys post-launch in order to obtain valuable information that allows us to improve service-centered value and our internal processes.

If you are stuck in that 84% that cannot deliver projects successfully or if your current processes or project management methodologies are preventing you from going above and beyond your client’s expectations, it might be the time to take a step back to analyze and restructure your framework to a way that will allow you to do so. We hope that these five tips are able to point you in the right direction to help you deliver your next project that achieves the status of project success.

Businesses love buzzwords. Many businesses will change their entire direction, sometimes against their better judgment, in an effort to attain the competitive edge the new “term” will give them. As quickly as trends come and go on the Internet, there simply is not enough time to research these new ideas thoroughly before implementing them. This leaves businesses not necessarily using the best practice or fully utilizing new concepts as they come down the pipes.

SEO (Search Engine Optimization) is one of these terms that has been spreading like wild fire. To compound the issues mentioned above, SEO is dictated by constantly evolving algorithms that are kept under lock and key by Search Engine companies.

Most people believe that the goal of SEO is to be “number one on Google.” This dogmatic mantra resonates through marketing meetings with cult like fervor. So much so that businesses are at times, losing site of the big picture.

The big picture is: the goal of your business. If your goal is to be number one on Google, then by all means, chant the mantra and go for it. However, most businesses are either offering a service or selling a product. With that in mind, while you are optimizing your site for search engines, make sure you are optimizing your site for customers.

It doesn’t do any good if you have a high rank on Google, but your website drives customers away in droves. Focus just as much on your site’s usability as well as its “findability.” SEO should be just one more tool in your marketing box, getting the same amount of attention as all of the others. An increase in traffic doesn’t equate to an increase in business. It simply increases the OPPORTUNITY to increase business.

While SEO is used in the context of being a magic bullet, know that it isn’t and use it for what it is originally intended and nothing more; and that’s simply making it easier for customers to find your site. The operative word here is “easier.” Not “the only” or the “best;” just easier. SEO, when working with other marketing initiatives will produce great results, but think of your marketing like a race car. When all the parts are functioning properly, the car will be able to stay competitive on the track. But regardless of how much work you put into the engine, your car won’t be going anywhere with flat tires.

Handing that baton off while running full speed is really a lot harder than you’d think it be. Despite how quickly it actually happens in real time, those teams have practiced it many times. The actual handoff occurs with a certain foot forward and a precise amount of time after the recipient of the baton has started moving. Most importantly, dropping the baton means losing the race!

Prior to any actual contractual agreements actually being in place for a project, it’s very likely that you’ve had several, if not many more, planning meetings with a sales-type person and probably even a pre-sales engineer. Think of this as the first lap of the race and playing the role of the baton are the project charter, initial project requirements, timelines, scopes of work, and situation specific details that could immediately affect the project.

In order for actual project, or second phase of the race, to get off on the right foot, it’s crucial that there be a clean handoff of this knowledge, or baton, to the members of the project team. How do you do this successfully? Just like a world class track and field relay team, it takes practice and an understanding of this fast, yet complex, interaction.

For our Galvin team, this occurs during the Project Kickoff meeting. If posssible, we prefer to have all key project stakeholders present. From the Galvin side, the personnel who are present are largely representative of the project scope itself. If its a database heavy application, we include our lead architect. Likewise, if we know that graphic or interactive design is a key component, we’ll include an interactive designer.

Once we’re able to get together there is a specific agenda that the meeting follows. This typically goes something like this:

1) Introduction to Roles and Responsbilities – We want to verify everyone’s role and responsbility in the project. Is there a 3rd party IT Manager who will be making DNS changes? Let’s identify and record that as a part of project foundation. Highlighting it early will avoid miscommunication later. Once again, no dropping the baton!

2) Highlight Project Objectives - This is where we’ll review the project scope of work and the Project Charter. This equates to not only what we’re setting out to do or how we’re going to, but to WHY the project has been authorized. In general, human beings work more efficiently when they understand the context in which they are working. We are at Galvin are no different. Bringing a general understanding of the project’s purpose can often generate new and creative solutions from unlikely places.

3) Project Specific Discussion Items - As a Project Manager, I always felt like this was the most important part of the kickoff meeting. This is because this is the spot where we openly discuss not only risks to the project, but how to mitigate those risks.

4) Next Steps – Very simply, where do we go from here? Next meetings, action items, etc.

At this point, we’ve succesfully handed the project off to the next runner in the race. Just like in a race, however, there are other handoffs that must occur as the project life cycle plays out. We’ll certainly cover these in later blog posts. In the meantime, just be thankful I don’t actually have any photos or videos from my high school gym class. It would be quite a sight!

Just think about how much time and money your organization puts into creating strategic and formal business plans. The meetings and the brainstorming and more meetings…all trying to account for everything, just so you can avoid surprises. We all know it only takes one bad one and the entire plan can be shot.

You might not realize it, but planning for a web site or web application is much of the same exercise. The difference is we call it ‘Discovery’ instead of Strategic or Formal Planning. Discovery has many purposes, but none so important as trying to account for as much as possible to avoid surprises later in the development cycle.

The trick is to consider what is included in that stack of paper. It’s likely a compilation project requirements, risks to the project, and most importantly, plans to mitigate those risks. Identifying both requirements and risks brings awareness of the possible issues to all project stakeholders. In this way, you not only know what you’re building, but what is out there that might trip you up, and how you’ll deal with it if or when it does happen. In short….no surprises!

Think of it this way, you wouldn’t build a house with proper plans. Show me an architect that cuts corners on your house and I’ll show you an architect without a job. If you’re serious about the project, be serious about planning. It really is that simple.

When it comes to any service that someone provides me, be it changing the oil in my car, getting a haircut, or even serving dinner at a local restaurant, providing me with good service always comes down to how well and how timely they communicate with me.

Are you running a little behind so my appointment is going to be a little later than expected? Or maybe the kitchen is out of what I ordered? All I ask is that you treat me the same way that you’d want to be treated in that situation and communicate those changes to me. Set and maintain my expectations throughout the experience and it’s highly likely that I’ll have a high opinion of my experience when I leave, even if it was a little late or not exactly what I wanted.

When it comes to servicing your website or web application, we here at Galvin believe those same rules apply. It’s because of this dedication to provide good customer service that we’ve implemented a structured support protocol that focuses on keeping our clients in the loop about the budget and timelines of their various requests.

A typical support request with Galvin would play out like this (see diagram as well):

1. Client reports request via email or phone to our dedicated Support Manager.
2. The Support Manager opens a Support Ticket and the client receives an automated email that a ticket has been opened on their behalf.
3. A confirmation email is sent to the client that restates the request and establishes a baseline for the cost of the completing the request and a completion date.
4. The client then confirms the request and the Galvin team begins work on the changes.
5. After the changes are completed, they are uploaded to a secure test server and a link is sent to the client so that they may review the changes prior to them being made public.
6. Once approved, the changes are pushed over to the live website or application.

As you can see, the entire process is focused on clear communication of budget and timeline so that the expectations are set and maintained right from the very beginning.