As a consultant and SharePoint developer, I usually have to gather requirements before I actually build a customer’s application. To have a successful project, it’s important that I maintain a healthy relationship of trust between my client and myself. With new clients, it takes time to build up that level of trust. There are several “landmines” that I need to avoid when dealing with my clients if I want my project to end up on a good note.
1. Assuming Clients Know SharePoint the Way I Do
I often build Publishing sites which usually have some kind of news article. When a publishing article is “old”, the article doesn’t get physically moved somewhere; it still sits in the “News” subsite. However, the Content Query Web Part that displays recent news articles will no longer display the article. Many customers tell me they want to “archive” news stories. For those who work with SharePoint, the term “archiving” usually means moving a file from one location to another, more permanent, records repository. When this kind of thing occurs, it’s easy for me to want to launch into a long explanation of “Do you really mean ‘archiving’ when you say ‘archiving’?” rather than simply doing what they mean and not what they say. When I go down these rabbit trails, I run the risk of a.) utterly confusing the client or b.) sounding like a know-it-all. I need my customers to believe that I understand their needs, and that I am approachable, rather than being some technical nerd who is unwilling to “talk on their level”, which will not help me win their trust when I need it later in the project.
I often build Publishing sites which usually have some kind of news article. When a publishing article is “old”, the article doesn’t get physically moved somewhere; it still sits in the “News” subsite. However, the Content Query Web Part that displays recent news articles will no longer display the article. Many customers tell me they want to “archive” news stories. For those who work with SharePoint, the term “archiving” usually means moving a file from one location to another, more permanent, records repository. When this kind of thing occurs, it’s easy for me to want to launch into a long explanation of “Do you really mean ‘archiving’ when you say ‘archiving’?” rather than simply doing what they mean and not what they say. When I go down these rabbit trails, I run the risk of a.) utterly confusing the client or b.) sounding like a know-it-all. I need my customers to believe that I understand their needs, and that I am approachable, rather than being some technical nerd who is unwilling to “talk on their level”, which will not help me win their trust when I need it later in the project.
2. Ignoring Pre-conceived Notions of What SharePoint Is and Does
I have one client who got hired on to her company because at her last client, she managed several thousand SharePoint sites. She thought she knew everything she needed to know about SharePoint. The thing is, every one of those thousand sites was an out-of-the-box site. Before she came on to this new company, I had built a highly customized SharePoint application for that company. (I’m talking a site that has FBA authentication synching to the SharePoint profile store, custom event receivers and item level permissions; you name it, the site had it.) Well, the amount of “moving parts” in the application coupled with a very non-technical user base meant that the site had occasional “issues”. She couldn’t understand why things weren’t as easy to fix as they had been at her old company. I have another client who worked at another company that implemented a Documentum web content management system and can’t understand why SharePoint doesn’t do what it did. In both scenarios, part of my job is to understand the assumptions my clients are making from the start, and use that as a basis for adjusting their expectations.
I have one client who got hired on to her company because at her last client, she managed several thousand SharePoint sites. She thought she knew everything she needed to know about SharePoint. The thing is, every one of those thousand sites was an out-of-the-box site. Before she came on to this new company, I had built a highly customized SharePoint application for that company. (I’m talking a site that has FBA authentication synching to the SharePoint profile store, custom event receivers and item level permissions; you name it, the site had it.) Well, the amount of “moving parts” in the application coupled with a very non-technical user base meant that the site had occasional “issues”. She couldn’t understand why things weren’t as easy to fix as they had been at her old company. I have another client who worked at another company that implemented a Documentum web content management system and can’t understand why SharePoint doesn’t do what it did. In both scenarios, part of my job is to understand the assumptions my clients are making from the start, and use that as a basis for adjusting their expectations.
3. Ignoring the Political Environment
During the requirements gathering process, it’s often necessary for me to ask innocuous questions such as “Do you want workflow on the news stories? Who approves them?” Seems like an easy enough question, right? Well, in some cases, that can be a loaded question. In many big companies, the Corporate Communications people making a living off of things like good grammar and understanding proper marketing strategies, whereas the clerical administrator in Accounting might not have the same gift for rhetoric. Knowing who should have control over those news stories from Accounting (as phenomenally interesting as I’m sure they are, coming from Accounting), can end up being a bigger deal than I ever thought. I need to be aware of the political implications of what I’m asking, even if the question is being driven by the desire to nail down a technical requirement.
During the requirements gathering process, it’s often necessary for me to ask innocuous questions such as “Do you want workflow on the news stories? Who approves them?” Seems like an easy enough question, right? Well, in some cases, that can be a loaded question. In many big companies, the Corporate Communications people making a living off of things like good grammar and understanding proper marketing strategies, whereas the clerical administrator in Accounting might not have the same gift for rhetoric. Knowing who should have control over those news stories from Accounting (as phenomenally interesting as I’m sure they are, coming from Accounting), can end up being a bigger deal than I ever thought. I need to be aware of the political implications of what I’m asking, even if the question is being driven by the desire to nail down a technical requirement.
4. Falling into the “Not My Responsibility” and the “My Way or the Highway” Traps
Earlier in my career, as a junior developer, I frequently got my hand slapped if I tried to take on the responsibility of managing a project. Unfortunately, I learned the lesson through the years that it was better that I didn’t make any decisions whatsoever when it came to the software I built for clients. As a result, I “nickel and dimed” some clients to death by asking them “Do you want this?”, “Do you want that?” On the other side of things, there can be times where I stop listening to the client when they say they want a particular feature, because what they are requesting is very unconventional. Sometimes I have to slow myself down enough to be able to differentiate between the “If you do this you will have very very bad problems down the road,” comments vs. “I’ve never seen it done before and why would you possibly want to do that,” type comments, which can come across to the client as, “Do it my way or else,” even if they have a legitimate need. At the end of the day, I need to take responsibility enough to provide a recommendation to the client when asked, but to take no offense if my recommendation is not adhered to.
5. Not Utilizing a Project Methodology
Is this project managed by the “waterfall” methodology? If so, you need to make sure you get your ducks in a row earlier than later, so that the client knows exactly what it is they are receiving. That way, if they want a change, they are aware from the get-go that they will need to submit a change request. If you’re loosey-goosey and you don’t set up this expectation up front, then if they start asking for additional features down the road, you’ll end up eating up all your hours and budget. However, on the flip side, this can come across as heavy-handed. If it becomes apparent that your customer wants a lot of “tweaks” to the system, then accommodate them, but transition your project to an “agile” type methodology, where you still have the ability to track progress and budget, but with a more side-by-side approach with your customer. It’s possible to still manage your project in a timely manner and on budget, as long as you are willing to be flexible and adjust project management strategies based on the needs of the client.
Is this project managed by the “waterfall” methodology? If so, you need to make sure you get your ducks in a row earlier than later, so that the client knows exactly what it is they are receiving. That way, if they want a change, they are aware from the get-go that they will need to submit a change request. If you’re loosey-goosey and you don’t set up this expectation up front, then if they start asking for additional features down the road, you’ll end up eating up all your hours and budget. However, on the flip side, this can come across as heavy-handed. If it becomes apparent that your customer wants a lot of “tweaks” to the system, then accommodate them, but transition your project to an “agile” type methodology, where you still have the ability to track progress and budget, but with a more side-by-side approach with your customer. It’s possible to still manage your project in a timely manner and on budget, as long as you are willing to be flexible and adjust project management strategies based on the needs of the client.
6. Not Paying Attention to Who’s Paying the Bill
I’ve had more than one client where the person in charge of managing the project was not the person paying the bills. The person I worked with on a day-to-day basis would give me a hundred and one requirements, then their boss would squash most of it in one fell swoop. I began to learn that it wasn’t worth investing a lot of time into certain requirements until I knew which requirements were a priority to the person footing the bill.
I’ve had more than one client where the person in charge of managing the project was not the person paying the bills. The person I worked with on a day-to-day basis would give me a hundred and one requirements, then their boss would squash most of it in one fell swoop. I began to learn that it wasn’t worth investing a lot of time into certain requirements until I knew which requirements were a priority to the person footing the bill.
For those other consultants out there, I’m sure you’ve run into similar issues. These are simply five of many tactics I’ve learned to adopt when working with customers who have hired me to build their SharePoint application.