I have recently discovered that many people don’t know what to expect and demand from a service provider. That’s why I decided to share with you this fresh piece of advice on productivity software and service providers. It may save your life, time and money.
A tale about an unhappy customer and a service provider with no profit
Let me tell you a story. Once upon a time there was a happy customer who wanted to have an application that would solve his problem. He prepared a request for proposal, chose a partner for delivering the app, agreed on a deadline, BUT… after a while nothing had been working as it should.
The customer looked at the final app and said: “What is that?!”. Everyone knows the feature he needed and that it always works in a specific, predictable way. And the application lacks this basic attribute, regardless of the fact that it’s a MUST-HAVE. It’s like building a house with no windows and doors.
The provider tried to fix the product, and after six nerve-racking, mostly sleepless months, the application was finally deployed. Well, the bad news is that it was over the budget, after the deadline, the customer was disappointed, and the partner ended up with no profit at all. And eventually, he was the one to be seen as a villain.
Do you, as a customer, need a Robin to help you fight such risks? How to avoid them? Does this story remind you of anything? If yes – then I may have a solution to your problem. Let me tell you what are the must-dos in IT projects.
1. Know the technology
In the recent Nielsen Norman Best Intranet report, one of the winning themes among participants was “Knowledge about technology” utilized when deploying the solution. In most cases of awarded intranets, it was SharePoint.
Every project we have performed as Predica (with a team knowledgeable about the technology) was developed significantly faster and cheaper when the customer’s team knew the basics about the product, its limitations and features. It then becomes much easier to imagine the result and articulate needs.
2. Trust your partner
After a long and acute process, you have eventually chosen your partners. They are presumably either one of the best experts you could find on the market, or they have a good ratio of price to performance.
One way or the other – do trust them. They have more experience than you do and you shall assume they’ll do anything they possibly can to deliver a product of the highest quality. If they say something is particularly difficult to implement, and it will be hard to manage – don’t be stubborn, change your requirements if you can.
Otherwise, you will end up with a solution which may be highly customized and usually very expensive in maintenance. Some consequences can be revealed after a longer time when more data is introduced into the system or more users start using it. In the case of SharePoint, complex data structures, large repositories or complicated security settings, can cause maintaining and upgrading such an application a real nightmare.
However, you may always ask: “OK, but what if I don’t trust my partners?” Well, fire them immediately – there’s nothing worse than working with people you don’t trust.
3. Read the documentation, know the scope
Oh boy, oh boy… If someone asked me what is the main reason for the problems occurring on the customer side of the project, I’d say it is simply not reading the documentation. I have tons of examples here to recall. Let’s face one of them…
Once a customer called me halfway through the project and said: “I will find and kill the person who signed the project scope! We wanted something completely different!”. However, we still had some budget left and it seemed we would be able to deliver what the customer desired. Oh Lord, how wrong I was…
What’s the lesson learned here? For both customers and tech partners – stop your project at that point. Get back to the design phase, think together about what you want to achieve and start it all again.
Now, let’s get back to the documents – as a customer, you have an obligation to READ AND UNDERSTAND every single piece of the project documentation. Especially the ones that have a significant impact on the scope – such as the RFP, Offer, Functional Design or Technical Design. Be engaged – always remember to read the documentation. There should be at least one person on your side who knows every page of the documents and every single requirement.
You may be surprised that tech design has a real impact on the features – well, at least it has in the case of SharePoint (but I doubt it’s different with other large Intranet or ECM platforms). The way we do some things in this magical Microsoft platform allows us to use specific features – I’ll give you some examples in a minute.
4. Be engaged, ask for status
Check the status of the project frequently. And by saying “frequently” I don’t mean “as often as possible”, but I mean “as often as it makes you comfortable and lets you keep things under control”. Now, how to measure your status? It’s quite simple.
Firstly – remember, there’s no such thing for IT as “97% complete”. It just means the task or feature is NOT READY yet, and the remaining 3% can take as long as the first 97% took.
We follow two things – completed user stories and number of bugs. User stories are your requirements described in the documentation. We measure how many user stories have been done (closed) per week. And having obtained the values, we can estimate when the project will end. But now, does it mean the user story is closed? No – it just means it has been checked by the tester.
And about those bugs… Remember there is no perfect developer. There must be some bugs reported by testers. If you can’t find them and get them fixed by the developers during the project, it only means chaos – chaos everywhere.
5. Ask and understand
You have the right to ask any question. Even if you find it stupid or obvious, I’m telling you… We have discovered many requirements just by asking simple questions.
You also have the right to understand. I often face people saying “I’m not technical”. That’s precisely the point! If you don’t get what the architect or developer says – ask for an explanation. And again. And again, if it’s still necessary.
The expert is indeed accountable for explaining stuff in a way the customer will understand, right? Be sure you know exactly how the application or the system you ordered works. It’s you who will be using it till the world ends! Not me 🙂
6. Get the deliverables that you paid for, set up a process
This is my recent discovery. We are now developing an extensive system previously created by another vendor. What a surprise it was when we discovered that we don’t have a key for generating the DLLs. The previous provider gave the customer a source code, but with no keys, you get it?
If you are not an expert in this matter, let me give you an example. Having a source without the keys is like having a car without the keys. You can look at it, sit inside, use the parts in other cars, someone who has the keys can give you a lift, but you cannot drive it on your own. Quite limiting, right?
I wonder how many customers are in such a situation, most probably unaware of that. If you have never compiled the source code by yourself, you can be in the same position. There is only one remedy for that. Set up a proper process and tools for passing the project deliverables to your IT. Your technical staff should prepare the installation package based on the components and source delivered by the service provider. It’s a part of Application Lifecycle Management, and at Predica we have a few smart guys who could help you with that.
Let me ask you a question. Can you spend from 20% up to 80% of your budget for the project variances? When estimating a project in a T&M mode, we don’t assume any risk buffers, etc. We often give a simple estimation of hours, but it requires budgeting flexibility on the customer side. So, if you have a goal of spending project money – you will probably do better with a Fixed Price contract. But if you can budget with flexibility – go for T&M.
Ask for a working application every month and test it – this way you’ll get your product quicker and cheaper. You will also be able to introduce changes more often and finish the project as soon as you get your satisfying solution.
At the end, I will put an “if” for you… Ready?
If, after reading this insightful piece, you are interested in scoping your applications – we can become your partner and create them for you through User Design Thinking. To see what we can do for you, just get in touch!