How To Keep Focus In Your IT Projects

Your company’s IT project implementation will bring a load of benefit to your organization as well as big transformations, whether from an individual business unit’s or whole organization’s, depending on the scale of the project. No matter its complexity, it will have a lot of challenges that an IT executive needs to overcome. I will discuss the big challenges in this article, together with how to overcome them, with the experience that I have learnt right in the field.
Many IT supervisors and managers tend to think that the biggest hurdle in an IT project is the technical side: server and network infrastructure, connections, integrations, tests and all that’s related to bits, bytes and packets. They are right from their own perspective, but looking at the overall picture, the technical issues are essentially “bits and bytes” compared to other barriers, as we will see.
Before beginning any project, we have to define why are we undertaking this project. What particular problem are we trying to solve? What is that particular thing that would make this project useless? What are the features required? What are the capabilities? Once we answer these questions and bring them together, we form the project’s shape. Later on we will put these on our roadmap.
When we have a clear definition, we will have the ability to work in parallel. Since the project is already defined in its essentials, we do not need to go top-down or bottom-up. Instead we can have multiple teams that work at the same time. If we had not clarified all of the items above, we would have to stick with various stacks and we would have to wait for each stack to complete in order to start the next.
This definition will also help both the project team and the users from “wandering.” In many cases people will lose focus on the big picture and the whole vision may be lost. This is not related to the business hierarchy – I have witnessed countless cases where newcomers kept perfect focus but the executives needed to be reminded of the project essentials time to time.
The next step is to define the architecture formally in the clearest way possible. All we need is a paper and pen and to define where we are putting all the elements – SANs, databases, clusters, switches, applications, web sites whatever. This step will allow us to see the complete picture first. Second, it allows us to discuss the project and its pieces with everyone involved. Third, we will be able to point out the places where we can scale up, scale out the system, the extensibility, management, backup/recovery and the mobility aspects.
This architectural drawing will enable us to see the end of the project. What is it supposed to look like when we finish it? That end state of the project is where we want to reach, so it is completely logical to work backwards from there. Consider the project of replacing a legacy IBM iSeries system and have everybody working on an Microsoft architecture (let’s say just a simple Windows Server, SQL Server, IIS setup), then we have a clear definition on the end result. How can we understand if we could accomplish this result or not? We will define this also: no connections to iSeries, all backups taken, restore tests successful and system powered down. Without having a well-drawn architecture and clear vision, we would not be able to have such clear definitions.
This drawing also helps to identify where the project can fail, what can go wrong and what are the items that we can expect? These questions are normally asked in the post-mortem analysis, but why wouldn’t we these questions beforehand so that we can see our risks and our opportunities. By this, we will be able to exercise our due diligence on the project. We will be able to look at from the perspective of “what would we do if we were buying this project.” And, we will be able to develop certain procedures, roadmaps, checklist for the scenarios we have identified.
The benefits do not end here. The architectural drawing will help us identify where we have the most opportunities to change. Consider the parallel work and the milestones that I have mentioned above. The drawing will show us where to start and how to proceed. With a little bit of thought on these, we will be able to identify the milestones and which resources we can bring together to accomplish the milestone so that we will be able to clear a big portion of work. To make myself a little clear, let me give you a small example. Suppose that we need to install 10 Remote Desktop servers. To do this, we will need to allocate them a certain space in our SAN and allocate virtual machines, define IP addresses, configure the load balancing, setup a golden image. Now imagine that the storage team is working on the SAN and the virtual infrastructure, the network team is working on the load balancer and the IP addresses and the Windows team working on the golden image. When all three teams complete their tasks and bring their results to the table, a big milestone will be cleared at once. In our projects, we will be on the lookout to identify such points.
When the project is starting to build up, we will load test it early on and we will do it often. That way, we will not only see how the system performs under pressure but also we will understand the bottlenecks, any mistakes that we have done in the architectural phase and how we can carry on. It is better to identify load test scenarios and the test criteria early on.
At this point, if the initial load tests results are good and if we are confident to move the project forward, and if the project has an end-user interface (to say, not something like a database migration but rather an in-house developed application), we will start working on the end user experience (UX). This is not the same as the end user interface, but the experience. We will call the UX experts and begin to discuss how we will handle the actual use of the program. If we do not start working on the UX issues at the beginning of the project, two things will happen: first, we will have a bad user interface (no doubt about it), second we will go back do additional work to ensure that the application can be used smoothly.
Once we arrive at this point, we will be pretty much confident that the project is taking off to a healthy progress. We will already have a great overview and be able to see more or less clear what’s ahead.
Do you have any other project tips that you want to discuss with us? We would love to hear your comments.
References

RELATED:   IaaS, PaaS and SaaS Explained