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.

• Be realistic with your deadlines. You might believe you can put pressure on external entities to help you deliver on your goals, but if you're doing so because you didn't put adequate planning in place or because you procrastinated it is unlikely anyone you partner with is going to be able to deliver in six months what you had to deliver in two years.
• Give out as much information as possible. Many of my customers host a single RFP briefing session. These are normally one to two hours and they tend to talk through most of them with a bit of lip-service to questions external organizations that are responding may wish to ask. I think the question window needs to be longer. Consider who benefits from that the most. Why would a customer not want an organization to be genuinely interested in getting the best result for them. Clarifying questions are critical to providing a response that meets the actual needs.
• Be sensitive to competitive advantage. Consulting organizations thrive on their IP. Its the secret sauces that gives them their competitive advantage. Often the very questions that make the most sense to be asked are simply not because the customer that issues the RFP insists on sharing all questions and answers with all parties. I recognize that some questions are obvious, such as, "how many workstations are affected by this project," and the customer may not want to answer those multiple times, but others are not. Consider that you may want to be engaging with an organization who is really prepared to think through the problems and resolve them, rather than an organization who grabs at IP and provides the cheapest bid. It's a tough balance to strike, but perhaps consider allowing people to ask questions in a way that they need not worry that their competitive advantage in IP is not thrown out of the window. Perhaps giving them the opportunity to ask up to five questions that will receive confidential answers may help out a bit.
• Be prepared for detailed discovery. RFP responses only go so far, and they're only as good as the questions asked and the respondent's understanding of your organization. They can't possibly be perfect, and in many instances should not be considered to be binding obligations. At best you'll have a good feel that their technology will fit and that the chosen organization will walk down the road with you and deliver what you need. Let the chosen respondent do a detailed discovery after they are chosen, in order that they can provide more specifics with a more detailed budget. That way there will be no surprises half way through the project and you're more likely to succeed.
• Do a proof-of-concept if you're battling to choose. Don't be afraid to request your short-list of companies to do a proof-of-concept (PoC) in your environment. Often the companies that are most likely to deliver will be baying for the opportunity. In doing so you will gain more confidence in choosing the correct supplier. Of course there is a caveat. You will need to plan and budget appropriately for your RFP. There are 'hidden' costs to an RFP you may not be thinking about. If a PoC is to be run in your environment you will probably need to have space to do so, connectivity, power and systems in places that can represent your environment to the degree that you can be confident the PoC is not a smoke and mirrors demonstration. If you're going to do it, do it properly.
• Price is important, but... don't expect a Bugatti Veyron for the price of a Volkswagen Golf. Furthermore, don't expect a Golf to function like a Veyron! Price is always important, but be very conscious of marrying your executives requirements and perceptions with the solution you have chosen. If you promised them the world a few years ago, and then issued an RFP just before your delivery deadline it is highly unlikely you will have the budget or time you had then to deliver the Veyron you're still selling them now. The best result at the best price only comes from proper planning and a distinct lack of procrastination. You might believe you can put pressure on suppliers, but is unlikely what you get will ever fit one hundred percent.

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.

• Understand the real risks. Don't outsource problems that cannot be resolved internally. Most often the problems I'm referring to here relate to internal politics, budget, management boundaries and business complexities. Put simply, if you don't have buy-in from key stakeholders for your project and you don't have the budget to do it, it is unlikely you'll find an external organization that can navigate the business complexities and also be cheap enough to solve your budget woes. Good consulting organizations can often help with one, but that will generally come at the expense of the other. Good resources are simply not cheap, but they're often more politically astute.
• Understand your IT Rhythm of of the Business. Most large business have a IT lifecycle they adhere to. This includes budget and planning cycles, upgrade cycles, change request windows and freeze periods. In setting deadlines it is critical organizations consider these time periods when they start setting project deadlines. Do it up front. Don't suddenly be surprised by an external organization challenging your deadlines because you didn't plan up front. It really is not their fault.
• Understand what you bring to the project. Your chosen supplier will be very dependent on internal staff contributions from your organization. This may be something as simple as input into workshops or document sign-offs, or more complex like working day to day with your project management office, depending on your company for procurement or for decisions that materially affect the project. In all cases these are critical dependencies for moving to the next phase of the project delivery. You will need to ensure the right people in your organization view the project with the right level of priority in order that you meet your project success criteria. It is far harder for external organizations to work with companies whose project sponsor is incapable of driving the right behaviour internally.
• Avoid asking for extras before the job is done. The 'how about we do this and that' conversation really needs to occur when all parties are satisfied the initial project objectives are going to be met. I often sit with customers who suddenly see the potential of what they're implementing and then want more from it straight away. It's an exciting time, and it's wonderful to see the enthusiasm, but it's also important to remember what has been contracted and that the additional work you're requesting translates to project scope creep. Scope creep often entails more time, more budget and more resources. Scope creep discussions also often delay work in progress. Be careful, and expect to pay more at a minimum. Responsible consulting organizations will often point this out, but it rarely reaches a willing ear.

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:

• Put real decision makers into your governance structure. It is no use placing ineffectual or unempowered team members into decision making bodies on the project. This will just result in delays and frustration. Rather schedule decision making body meetings appropriately in order to ensure the decisions makers can be in the room when decisions are needed.
• Insist on detailed project management and budget tracking. Sounds simple enough doesn't it. Yet it doesn't happen as often as you would think. Here's a hint. A spreadsheet of servers to be replaced or upgraded does not constitute a project plan; it's part of an implementation plan. Many of my customers work with external organizations and magically run out of budget at the eighty percent of delivery mark. It's usually because the budget wasn't being tracked effectively. Tracking the budget properly will help you determine if more is needed well in advance of it becoming an emergency. It will also ensure you meet your goals on time and within budget. Disciplined and well trained project managers will do this as a matter of course if they're given the time to do so. Ensure you support them in doing so.

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.

• Procurement needs to be done early. Be realistic though. Until a hardware design is completed you can't expect proper specifications for what is required. Put the hardware design tasks as close to the beginning of the project and create a finish-to-start task that kicks off procurement as soon as it is complete. Be realistic about your deadlines in this regards. Hardware procurement time frames and hardware shortages often cause delivery delays in the project.
• Operations is part of the project. Operations is not something you tack on at the end of the project. That team should be an intrinsic part of the project from the outset. Their is nothing like a, "that will never work because the procedure for that is..." comment to derail the best laid plans. The more input you have and the more knowledge you disseminate to the operations team within your project the more likely you are to succeed. Furthermore, having the operations team in your project is more likely to help you understand what it will costs to train or acquire the skills necessary to operate your solution.
• Real skill doesn't come from "knowledge transfer". Although on the job training and hand-holding is useful, all it really does is help operations staff become relatively proficient at the subset of the solution you're showing them. For staff who need to support the solution there is no substitute for formal training, certification and participation in creation of the test cases and performing the actual testing.
• Operations staff are people too. Spend some time considering them when you're making a product choice. Although it might seem like a brilliant idea to implement a REXX-based application on IBM OS/2, you might have a hard time finding skills to maintain the solution or persuading operations staff to learn it because it's hardly a compelling step in their career. Attracting and retaining good operations staff to your organization is critical to keeping your environment running. In the short-term it may seem like you're pandering to their needs, but in the longer term it's actually an important consideration in maintaining your investment in the solution and its long-term viability.

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?

This post is governed under the site terms of use and by the Creative Commons Attribution-NonCommercial-NoDerivs license. Original work of Natasha Anne Mocke.You may republish this work as long as explicit credit is given to the author.