Interview with Steve Short, President, NetLink Resource Group
Many IT vendors and integrators often forget that the path to a truly successful IT implementation is paved with baby steps. All too often, the traditional method for managing a project is to show the client the result of the technical effort at the very end of an engagement. This project management method can cause delays and even derail entire projects.
NetLink Resource Group prefers an “iterative approach” for managing the implementation of web solutions that mitigate many common risks of IT projects and enables their project teams to deliver superior solutions to clients while staying within schedule and budget commitments. Steve Short, who became President of NetLink in April 2004, has used his more than 20 years of IT management experience and the company’s close interaction with clients on project implementations to develop the organization’s unique, six-step approach they refer to as the “NetLink Adaptive Process™”.
The following is an exclusive Q&A with Steve Short, where he discusses the details of the company’s Adaptive Process.
Interviewer: First, tell us about NetLink Resource Group.
Steve Short: NetLink develops web solutions for our clients, although our role typically extends beyond just providing programming resources. Essentially, we are a consulting practice that provides web strategy and technology solutions to support our clients’ business goals and efforts. It’s really all about developing web solutions that have tangible and measurable business benefits. We can handle any project in terms of size and sophistication, although we tend to focus on efforts with a high level of complexity.
Interviewer: Great. Tell us about NetLink’s iterative approach to project implementations that you call the Adaptive Process.
Steve Short: Sure. The Adaptive Process is all about getting solutions in front of clients sooner rather than later. This means that we have a system for meeting the goals for projects by doing more upfront project planning, defining requirements– with plenty of client input along the way.
Once you do this, you are more apt to meet the requirements of the project, accomplish key goals and milestones more efficiently, and come in on budget. This also allows us to be in sync with what our clients have defined as their needs or their requirements. By doing this, we mitigate any serious problems that can arise during the life cycle of a project.
Interviewer: Tell us why your project management approach is unique.
Steve Short: The iterative approach is well-known and documented in IT circles, so most business sponsors are familiar with the terminology. Unfortunately, their experience with IT projects that were supposed to use the iterative approach often leaves them wondering about the benefits, and often feeling underwhelmed with the final product. Every consulting firm claims to have their own unique methodology, so I’d rather say that in using our Adaptive Process, we focus more on execution, or where the “rubber meets the road.”
We spend a tremendous amount of time upfront trying to understand our client’s project and business goals at the very outset of the engagement. By strict definition, this is the “requirements” part of the implementation and it is one of the most critical times of a project. This is where many of the early problems can arise because both business and IT people can’t often differentiate requirements from solutions.
My experience of managing IT efforts over the last 20 plus years is that project teams tend to stab blindly in the dark by coming up with a solution first without really listening to the client’s requirements and business needs. What’s needed is a project leader that listens to the project sponsors, differentiates requirements from solutions, and documents them in a language that is understood by the business people as well as the IT folks.
This allows the IT team to use their experience to formulate a solution that is better in terms of usability, functionality, and architectural flexibility that would have been missed if they relied upon pseudo-solutions proposed by the client at the onset of the project.
The reality is that for any one requirement, there can often be multiple solutions. So, once we truly comprehend the goals and requirements of an effort, what our project teams bring to the table are creativity, an understanding of the technology available to meet requirements, and experience to formulate solutions that are better than those conceived by the client at the onset of the project.
Interviewer: Great. That covers Step One of the Adaptive Process, which is the requirements definition section. Now, let’s discuss Step Two, which is the technical analysis portion.
Steve Short: In some ways, the technical analysis overlaps with the requirements definition portion of the process, because we need to inform the client of what might be accomplished from a technical standpoint when requirements are being defined. In other words, we take a “blue sky” approach during the requirements phase by asking the client for their ideal goals of the project but settle on needs that can be realistically met based upon current technology constraints and budget. This is where the process for implementing a successful project is not fully linear– while the methodology defines distinct steps along the way, you have to use experience to suggest basic approaches that keeps the project moving forward.
Once the requirements are nailed down, the technical team determines the best way to architect the actual project. Because we focus heavily on the requirements portion of the process– including taking future requirements into consideration– this step is fairly easy for us.
As I mentioned, this is really all about making sure that the technical team understands the requirements and develops an architecture that allows us to formulate the best solutions. It is our lead consultant’s job to bridge that gap between the requirements and the technical approach to ensure that we accomplish this. Doing so often leads us to consider how we plan to execute our proposed approach, which is the next step.
Interviewer: Let’s talk about Step Three, the next phase, which is planning.
Steve Short: Yes, this is an important phase. Once you have determined the requirements and come up with the technical approach, it all comes down to developing an actionable project plan. Many iterative processes have the planning step listed first and you obviously know you will follow the basic steps taken for every project, but we believe we need a firm understanding of requirements and technical approach to develop a project plan with any credibility.
For us, a very important part of project planning is identifying high-risk areas and determining how best to mitigate them. More specifically, it is vital to identify the highest risk elements of the application or project before any significant development occurs or you risk exceeding your schedule and budget commitments. With that in mind, we develop a plan that mitigates these risks by effectively dealing with high-risk tasks and deliverables as early in the project as possible. Most of the detailed planning revolves around the development tasks.
Interviewer: Can you give us an example?
Steve Short: OK. Take the development of an e-commerce website, for example, since most of us have made purchases over the Internet and it’s something we can relate to. Let’s say we’re most concerned that the page where the customer chooses products will have the greatest complexity because it needs to be easy to navigate but requires a great deal of dynamic decision making in the software to provide the best customer experience. In addition, we may have concerns about our proposed approach to the technical architecture behind the scenes, where we want to be sure that response times are adequate for the functionality occurring on the page.
We would want to tackle this work first because the rest of the site’s functionality will flow from this page and the site won’t be as effective as it could be if we don’t determine the best solutions for it early in the project. To assure we’re heading in the right direction, we want to get a first iteration of this page delivered to the client as soon as possible, so they can let us know if the proposed solution really works.
I have an MBA with a concentration in marketing and one of my favorite MBA courses was in product development. Some core strategies for product development are prototyping, proof of concept, getting feedback on solutions, and reiterating as often as possible to develop the best product. I think that the development of web solutions should use the same approach.
Interviewer: That makes sense. So, finish up the planning phase for us.
Steve Short: Sure. Once the riskier items have been prioritized, the plan can focus on getting the rest of the deliverables completed. Throughout the course of the project, you need a plan that everyone can understand, in terms of concrete tasks and deliverables. And when I say everyone, I mean the client — sponsors and stakeholders; the lead consultant managing the project; and the technical team implementing the solutions.
We’ve found that it’s usually best to have deliverables relate directly to the core requirements to make this possible. This makes it easier for everyone to track the progress of the work throughout the project and it avoids surprises in terms of schedule and budget.
Now, it’s important to point out that project plans are rarely static — they need to change based on new information that is derived throughout the course of the implementation, so we have to be nimble as well as linear in our approach. For example, plans change if the proof-of-concept had outcomes that you weren’t expecting or they can change if items got done sooner rather than later. In addition, the client may add requirements that are deemed essential to the success of the project, so the plan needs to go through iterations just like the software.
What we know is that when you don’t have a formalized plan that you follow and update as necessary, the pitfalls are tremendous. It can cause the technical team to develop solutions without any real strategic direction or without the business goals in mind. More often than not, in these types of situations, the work needs to be re-done and projects go over time and budget.
We’ve seen this in cases where we’ve been brought in to consult on projects where the IT effort is way off course. In addition to a poor definition of requirements, the root cause of problems usually stems from the lack of having a project plan that has been maintained and used as a tool for managing the effort. Oftentimes the project sponsor requests a project plan with the RFP response or at the onset of the effort but doesn’t realize that the IT team responsible for the implementation should be using it as a means to direct the project.
If the intent of the IT team is to create a plan solely to satisfy the client’s desire to have one and it’s not used to manage the effort, it really provides no value. In effect, it becomes nothing more than an approach document. Telling a client your approach at the beginning of a project but not tailoring it as the effort evolves with a living, breathing plan is not a viable way to manage a project. Having a plan that is regularly evaluated helps you track your progress, review resource allocations, and assess risks to allow you to mitigate them.
Interviewer: Great. Now let’s talk about Step Four of the Adaptive Process, which is development, Quality Assurance (QA) testing and delivery.
Steve Short: This is the nuts and bolts of the project — the phase where the development team does the majority of the work. To the average business person, the development part is somewhat of a mystery. The developers go off and plug away at coding, and then suddenly the client has something to review.
If you are a stakeholder, what can be frustrating is when you wait for a long time while this mystery phase is happening and you wonder how the effort is going and whether the deliverable will live up to your expectations. If the project is not complex and has a relatively small level of effort, it may be reasonable that you see a first pass of the entire solution in a single delivery. However, when the effort is larger and more complex, you should expect more portions of the solution to be delivered incrementally, rather than getting everything in one shot.
If you’re not getting this, then the IT team that claims to be taking an iterative approach is not really living up to the methodology. Their interpretation of the iterative approach is that they deliver everything and then make adjustments based on your feedback of their single delivery. If the development effort requires 100 hours that may be reasonable, but if it’s closer to 1,000 hours, do you want to wait that long to see what the developers are coming up with? It all comes back to risk. The role of business people and managers is to mitigate risk — it’s a consideration in everything you do.
So, is it reasonable to risk waiting for an IT team to spend hundreds of hours of development time before you have seen what they have accomplished? We don’t think so. At least, we don’t think that our clients would be comfortable with this kind of project methodology. But it all comes back to the planning phase and the IT team’s responsibility to build a plan that determines which portions should be delivered for client review before the entire, integrated solution is ready for testing.
Something that is equally frustrating to business sponsors is when the development phase of a large effort goes on without any questions from the IT team. Regardless of how well-defined the requirements are the developers should have questions about the details. Going back to reasonability — is it reasonable to think that a group of developers would have no questions about an effort that requires hundreds of hours of development time? We think not, which is why we would expect our clients to anticipate an ongoing dialogue with us while we are in the process of developing a solution for them.
The only way to make this happen is to have a team of seasoned web developers with a mindset of knowing when to ask questions. Even in cases where there are detailed specifications, questions should arise.
And, of course, the QA testing of the project is vital before we deliver anything to the client. We actually think like the client and see if it truly meets their needs. Rather than focusing on testing to see if the application or project works, we take it one step further by determining if we actually solved the problem, or met the goals highlighted in the original plan.
Interviewer: Tell us about Step Five — client evaluation and testing.
Steve Short: Yes, we actually get to see the project come alive when the client conducts their initial evaluation and testing. By following our Adaptive Process closely, we are often just tweaking and refining. However, with a larger and more complex project, we would typically be delivering a module or “chunk” for the client to evaluate while we’re off developing the next module. It’s possible that the feedback we get from the client at this point will impact the next deliverable we’re working on or at least the remaining work that needs to be accomplished. This is often needed because clients add on new requirements and that is totally fine.
This is where a complex project implementation requires us to be flexible so that we accomplish evolving goals for our client, yet disciplined enough to follow our Adaptive Process. It entails re-evaluating our plan based upon the client’s feedback and adapting it to the current needs of the project. This is Step 6 — address client feedback and re-evaluate, where we come full circle in the process.
Interviewer: And then you deploy?
Steve Short: Yes, but let’s take a step back. Before we actually deploy, we have gone through the full Adaptive Process — especially when new requirements are introduced — as many times as needed. This requires reiterating on all of the steps to ensure we stay true to the methodology and provide a solution that meets all of the client’s goals. Once we have achieved this, it is time to officially put the project into production.
Interviewer: Thank you for walking us through the Adaptive Process. Anything else you would like to add?
Steve Short: Yes, I would note that it ultimately comes down to execution, discipline, and attention to detail. You may have a defined process but you really have to have the people in place that understand it, believe in it, and follow it.
That’s not as easy to accomplish as it would seem, especially when a project has a high level of complexity. It’s probably why many executives and managers are often skeptical about undertaking IT projects that try to accomplish business goals and you can’t blame them. Fortunately, we’ve found that when we stay true to the Adaptive Process, the projects we undertake are successful in meeting our clients’ business objectives. And, that’s what it’s really all about.