In the many years I've been consulting as a Lead Technical Consultant, Architect and Engagement Manager there are a number of things I've learned from the school of hard knocks. Many things are obvious, and some less so. We can often find methodologies and material about how to run projects effectively, but rarely have I seen anything that discusses infrastructure design and implementation that includes information about how customers and consulting organizations can work together more effectively. This is a rather troubling situation, as many large enterprises work with external organizations to get projects delivered.
In this entry I'll discuss some of the main areas of concern I encounter in trying to enable my customers to operate projects more effectively. I'm focusing on the practical issues I encounter, rather than rehashing project management disciplines and methodologies. While those are important there are better places to read about them than on this blog.
1. Understand what an infrastructure project is?
Sounds obvious doesn't it, but most of the time it simply is not so. When I speak to customers, and even my peers, at the company I work for an Infrastructure project is usually some kind of storage, file and print, OS deployment, software distribution or messaging project.
Rarely do people consider that infrastructure, more often than not, provides the non-functional elements of an application development project. Some of my customers get it right, but most do not. Developers are not infrastructure people. They are more concerned with making it work, rather than being focused on redundancy, high-availability or operational environments. And rightly so! The problem is many people expect that developers can run SETUP and get things going, so they don't bother initiating an infrastructure project or sub-project in application development projects. This often leads to fantastic application development work not translating to success because the infrastructure belt and braces are simply not there to deploy and run the application successfully.
2. There is no such thing as a perfect RFP
Many of my customers create requests for proposals (RFP). Although this is an exciting time in their lives, and involves lots research and due diligence, the actual project delivery that results from the response they choose to ordain fails miserably. Most of the time it's because of simple things that could easily be corrected in their approach.
Firstly, try to remember that when you are creating an RFP you are asking an external entity to walk down a road with you. In partnering on any project of significant complexity it is better to understand what this might mean.
3. Be Realistic
Now that sounds silly. It is a project and it has to be realistic. Unfortunately often this is not the case. There are a few things that we think are simple at the outset of a project, that simply end up derailing the project, and most especially the project schedule.
4. Architecture is good, but
An enterprise architecture is extremely important, I'm not suggesting otherwise. Often I encounter architects that create a desired state architecture for their organizations and then expect that it can be delivered within the businesses' constraints. Businesses have budgets and deadlines and require a return on their investments. Except in the case of legislative compliance, there is usually a requirement to compromise between desired state and the business constraints.
In implementing new technology, it is usually important to understand that it is positioned at a point in your roadmap to reaching a desired state. It is unlikely it will be the perfect fit. It will usually be the best fit for what is possible within the business constraints. Understand that and you're most of the way towards setting yourself realistic expectations of what can be achieved in the project you're undertaking.
5. Avoid Snake Oil
A huge problem in actually setting realistic project success factors is Marketechture. Often the hardball sales techniques employed by vendors and external organizations will look fantastic in a presentation or brochure, but may not translate to action or actual delivery as anticipated. We can all promise you the Earth with a "little" development work, but how many organizations can provide you that realistically. Take a careful look at what will actually work well for your architecture, get the technical and project people in your organization together with the vendor and external organization and do the research you can to try and make the best decision. Snake Oil rarely cures your ills.
6. Governance is not just a pain in the neck
Put governance in place for your projects, not just because it's a nice to have, but because it is critical to project success. As there is a lot of material about project governance available I'm not going into any detail on the subject here, save to say:
7. Test the real deliverables
It's an obvious and short point, but a critical one. Spend time testing what you're expecting to be getting, not simply testing a product for what it should deliver. For example, testing an email system to see if it can send email from one user to another is probably a waste of time. Rather test it to see if it can send the types of emails you wish to send within the time frames you desire and on the bandwidth you have available. Test your customizations too.
Many companies will pay lip service about their project delivery methodology and will bang on about test leads and test cases, but many will also test the most rudimentary things only in order that they fulfil the test promises they made. This will result in expenditure, both in terms of schedule and budget, and will not help you achieve the desired results for your organizations.
Always allow your users to create the test criteria and participate in the actual testing. Never outsource those.
8. Failure to launch
Just as projects are about to be implemented, the failure occurs. It's great to have a perfect design, and have passed all the testing, but implementation disciplines and operational effectiveness are just as critical for your project's success. Once again, there is a lot of material about these disciplines out there. All I'm doing is highlighting those issues I encounter frequently.
I realize some of these points seem obvious, and others a little silly, but consider this. If they're so obvious and so silly then why do I encounter these issues in many of my customers constantly?
Brilliant. Unfortunately customers inevitably take a stance of "us vs. them" when putting out an RFP 9possibly in self-defence against aggressive vendors). However, they are the ones who pay the price when they end up trying to execute on a badly-scoped and planned project, based on a half-baked RFP response, because the vendor and customer did not understand each other's needs during this crucial early phase.
The two most common mistakes I see customers making when they put out an RFP:
1. Vague requirements. Sometimes I get the idea that whomever put the RFP together appears to have a clear picture of what is required, but this appears to be a super-secret, so the real requirement are only hinted at in the RFP. If vendors have to guess what you want, don't be surprised if you don't get it. Unfortunately, if a vendor under-scoped the project at the proposal stage, it is often difficult to renegotiate the proposed price. This leads to vendors trying to squeeze unrealistic amounts of effort into the project, without ggrowing the budhet. This might sound like a splendid position for the customer to be in, but it leads to badly-executed projects.
2. Asking for too much too soon. Customers obviously want to get as much as possible for their money. This unfortunately leads to an inclination to "pad" an RFP with requirements that *could* conceivably be delivered within an initial project, but should rather be deferred to subsequent follow-on projects (maybe a long-term program of action). I have been involved in a few of these "Big Bang" projects that tried to transform an IT environment in one short project. These mega-projects often caused massive business disruption and fail to deliver value, because they simply exceed the ability of the customer's IT organization to learn new skills fast enough.