Archive for December, 2007
We’ve posted a couple different articles about the good and bad of search engine optimization. Here’s a couple articles on Google’s removal of thousands of malware sites from its index, courtesy of Slashdot.
“The attack was directed at Google in particular and resulted in tens of thousands of Web pages hosting exploits showing up on the first page of Google searches for thousands of common terms (PDF).”
Related Links:
How I Learned to Stop Worrying and Love the SOW
In order to deliver what you promise, you have to understand what you’re promising. The fundamental piece of this puzzle is a statement of work. Any good statement of work should protect the interests of both the service provider and the client. Key components of the SOW include:
- Stakeholders (Client and Provider personnel involved in the project)
- A name and description of the project
- Listing of tasks and milestones (if the project is lengthy or requires client approval before proceeding)
- Listing of deliverables and any caveats to the use of those deliverables (more on this later)
- Project start date and estimated duration (including duration of effort by hours)
- Estimated fees
- Project assumptions (the catch-all, more on this in a bit as well)
- Execution statements and signatures
So, at this point, you’re saying to yourself, “Self, I’ve had Business Law 101, I know you need a contract and those things just make sense.” And you would be right, its pretty basic stuff that SHOULD be common sense. But common sense is like that lazy guy in the next cube who golfs with the boss and seems to be on vacation every other week.
Say you write an iron-clad SOW that follows the text book example to a tee. What’s the worst that can happen? Allow me to share a few of my own experiences. The three biggest pitfalls lie in the middle of the SOW: tasks and milestones, deliverables and caveats, and estimated duration. The biggest takeaway for this article is to really think through things when you write an SOW. Certainly, the statement of work will be derived largely from the proposal and negotiating process. But even once frameworks and milestones are agreed upon, there’s still quite a large margin for error. It’s important to keep these things in mind that I’ve learned over the course of my career.
1. Don’t include a task/deliverable that you aren’t completely sure you can carry out in the time allotted for the project.
2. Don’t include tasks/deliverables that go above and beyond what’s required to fulfill the terms of the contract. There’s plenty of chance to go above and beyond anyway if time and resources allow, but the contract should not stipulate this.
3. Tasks/deliverables included in the SOW should be clear and specific. You don’t want to leave any room for interpretation of what a task truly means. This can lead to significant financial impact in project delays, additional resource requirements, or worst-case, litigation.
4. Stipulations should be included as to how the client can use your deliverables, reports, findings, and intellectual property once the project is complete. This includes sharing with third parties, use of findings for strategic and tactical planning, etc.
At this point, I need to say that I’m not a lawyer, this is not legal advice, and any such guidance should be obtained from a lawyer when developing a generic statement of work for future use. Now that that’s out of the way, just a few personal stories on how these things can impact the people actually doing the work.
I’ve found myself on numerous occasions doing work that wasn’t part of the original scope because of vague statements about deliverables or tasks to be completed. In managing the daily activities of the project, I often find myself referring to the SOW to make sure we’re doing everything we said we would. Nothing is better than getting to a line item and saying to yourself “What the hell does this mean?” Because you know the client has a very specific idea of what it means, and of course, the client is always right.
I’ve also experienced cases where the someone wanted to get flowery with the description of a deliverable. If you can promise a report that shows site traffic over the past 6 months, you don’t need to promise a novel that shows the traffic, slices and dices the data 10 different ways, contains pretty pictures, and contains an instant weight loss remedy. If time allows, you can certainly deliver the novel, but then its seen as value-added, and not expected.
In the end, the SOW can determine the success or failure of a project before it even starts. It’s important to set yourself up on the right foot. The nature of projects is that there’s plenty of things that can happen out of your control, make sure you do everything that IS in your control right.
Have you experienced a situation where unclear statements of work caused project headaches or worse? Have you experienced a situation where a provider promised one thing and you were expecting something else? Let’s hear from you.
In my previous articles, I took some more fundamental IT theory and applied it (for better or worse) to SEO. As part of an occasional series, I’m going to pull it up out of the weeds a little bit and focus more on project sales and delivery from my own experience and perspective. My hope is that my own recollections can spur some conversation from readers about their good and bad experiences and that we can all learn a little bit in the process. So without further ado, I give you Part 1:
Know Thyself
Clients are generally smart people. This is something that many professionals in service delivery choose to ignore. In any given proposal process, you may have 10 people on a selection committee, and you may successfully BS 8 of them. But there’s always going to be 1 or 2 naturally cynical people, who through that cynicism fulfill the blind squirrel-nut theory. Keep in mind that during this process, you’ll be standing in a room explaining to this group why your product is the best for them, why the organization can’t get your skills anywhere else, and why they should pay a premium for an outsider to come in rather than do the work in-house.
Based on past experience, “The 8″ (as I’ll henceforth call them) are probably mid-to-upper/executive management from all business process areas. Strategic thinkers interested in the long-term and the financial in nature. “The 2″ are probably direct reports or low-to-mid management. They will be impacted most immediately and on a larger scale than “The 8″. They’re tactical thinkers, interested in day-to-day operations. How do you reach both groups, sell your services, foster partnership, and, hopefully, reap benefits for both parties?
The Value Proposition
Developing a value proposition is one of the most important and time consuming activities a service provider can do. Significant thought needs to go into first deciding what it is that you’ll do, then deciding how you’ll do it. And all the while, you need to be able to articulate how what you offer and how you offer it will provide benefit to the client in a way that separates you from your competition. For established providers, the value prop is easier to articulate and has probably evolved over time. For a startup, it can be daunting.
And so it comes back to the old adage, “Know Thyself”. It can be tempting as a startup to say “We need clients, so we’ll do whatever they want us to do and hopefully something will stick.” But that can lead to an identity crisis for the organization and can distract it from doing what it’s good at or what the original intent was. So how can you develop a value proposition that you can stand behind and can win work.
- What the organization does?
This should be a straightforward, simple sentence (think nouns and verbs with as few ad-words as possible). “ElectronSEO enables clients to better reach and retain customers by…”
- How the organization does what they do?
This should contain the services you provide at a high level. Things like copywriting, linking strategies, reciprocal agreements, website design, etc.
- What are the benefits to the organization?
At this point, you may be tempted to put in some bulletpoints you found on the net about potential gains a client can achieve. But this should be at a higher level. You don’t want to start promising specifics that will never be met. Statements suitable for this can be “Measurable increase in website traffic” or “Enhanced search engine results”. It may seem like a cop out, but it can save you from legal issues down the road.
With a well-developed value proposition, you can be better equipped to respond to RFP’s or to cold-sell your services to an organization. Research will aid you in tailoring the value prop to the specific needs of the organization so that both “The 8″ and “The 2″ will be in your camp.
What are your experiences? Have you been involved in a selection process and one of your potential partners couldn’t tell what they did to save their life? Have you developed a value proposition that worked on the first try or took multiple iterations to get right? Let’s hear your thoughts.