The people on the project team are the experts. Listen to them.
The people on the project team are the experts. Have their backs.
When the team decides where the project should start and when it should end, you need to enforce those points.
The most successful projects involve some scope change, some disagreements, some rework and additional costs. Management’s role is to commit to seeing it through, but not let it get out of control.
Successful CI implementations are built around excellent communication. Some would consider it over communication. Whatever mechanism your implementation follows, (I have seen email, standing meetings, messaging apps like Slack, shared storage and daily briefings) make sure everyone participates and makes frequent updates. Successful projects don’t get out of sync because one team has changed an assumption and no one knew about it.
Successful projects do however, have disagreements, arguments, fights, egos and blame. The key here is how those things are resolved. Everyone on the project has to be willing to communicate.
This communication has to flow up and down the management chain. If the project team feels like they have commitment from management, and the time and authority to succeed, those negative parts of human interaction will be worked out.
I have seen time and time again, when professionals are treated like professional, amazing things happen. There is no need to cast blame if no one fears that management is going to come in and kill the project because of a one-week time slip. No one is jockeying for position if the whole team knows what is going on all the time (information is only a weapon if a select few have it).
When communication is healthy, no one fears being the messenger and problems are raised quickly and solved quickly. When everyone knows the timelines, there are no surprise deadlines.
Some of this sounds obvious, but I have seen many projects get stalled simply because someone didn’t know they had a deliverable, and while everyone else was waiting for that deliverable, other things came up. Before we knew it, two months had gone by and no one was doing anything. True story.
In order to have a successful project, I follow this simple rule of communication:
Tell them what you are going to tell them. Tell them. Tell them again. Ask if there are any questions. Tell them what you just told them. Repeat.
At this point, you may have chosen your CI vendor and partner, or at least have it narrowed down. Which brings us to the final element required for a successful project.
6. Supporting Technology
CI projects are a bit different than many IT projects in that they are both a back-office tool and a customer-facing tool. This means that there are lots of dependencies on other pieces of technology, and lots of supporting technologies required.
What hardware is being used? What is the OS? What database technology is required? How do we integrate?
I cannot stress enough how important it is to use the most current, modern, fastest and most powerful supported hardware. I have never seen a truly successful project on repurposed hardware. Sure, some of them installed and configured well, but performance or the need for constant patching made user adoption rates very low. Follow the vendor recommendations. It is much easier to deal with too much capacity than too little. If this is a cloud conversation, the guidelines are really no different. The hardware is just in the cloud.
When evaluating operating systems and databases, there are two strategies. Pick one.
The first strategy is to go with what you know. If you have a lot of Windows OS experts, or a lot of Oracle DBAs, leverage that expertise. (see section 2 on the right people)
The second strategy is to go with the technology of your future. Are you moving toward Linux and open source databases? Are you consolidating across platforms? Are you adopting integration standards?
Whatever you choose, the critical factor is commitment. If you go the route of modernizing or standardizing, realize that there will be other systems that might have to migrate as well. There will be additional cost in retraining, or finding new expert resources. This is especially true when talking about the databases. Going back to where we started, data is crucial to CI projects. So is the supporting technology. And the people.
This list of success factors is by no means all encompassing. There are lots of other factors. This list looks at six major elements that contribute to a successful CI implementation. My experience has shown that you cannot complete a CI project successfully if even one of these areas is subpar. You can hit deadlines and check off deliverables, but in the end, projects that missed even one of these factors risk eventually being abandoned all together, or even worse, become the dreaded shelf ware.
I trust that you found this useful in the sales cycle and as something to use to answer those tough questions about success. In a future post, I will cover how SAS is the vendor that can best help in all of these areas