This documentation is archived and is not being maintained.
Business of IT Successful Project Management
There’s no question that today’s technology environment presents increasing and rapidly changing challenges for IT organizations. With the proliferation of social media, smartphones, intranets, extranets, and a slew of other technologies, the job of the IT professional has evolved from the simple management of servers and infrastructure in a data center to one that approaches that of the fully fledged product software developer.
Add to this the current economic troubles that are forcing many companies to implement cost-cutting and personnel reductions, and there's more pressure than ever on IT departments. Moreover, despite all these challenges, you still have to manage the servers and the infrastructure and you still have to deliver on more projects than ever before—with fewer resources. In the face of these challenges, project management techniques and managing upwards become the necessary tools that can ensure the success of a project that might otherwise crash.
One of the problems I have experienced over and over in my career is the fact that highly technical people often have a natural distrust of management. This is usually caused by the fact that the managers seldom come from the same background and thus have different expectations with regards to the complexity of developing and delivering on a project. This in turn frustrates the development team and forces them to take, in many cases, a standoffish position or even an "I told you so" stance that will eventually bounce the blame right back to them if the project fails. The problem is essentially the inability to communicate effectively to a management chain that doesn't really speak the same language. Unfortunately, this is an all-too-common story. We think we have effectively communicated the risks and don't realize until it is too late that we have not been understood. Unfortunately, the attitude that it's not our problem can result in failures even on some very technically solid projects.
Some projects, as I'm sure you've seen, seem to be doomed from the very beginning. Even experienced folks will put in lots of late nights trying to solve bad management decisions with technical proficiencies; unfortunately, in many cases that is simply not possible. When that happens, instead of taking the approach that it is not your problem, you are much better off stopping, discovering where the real issues with the project are, and then addressing them, rather than making a heroic effort in the hope that the project will be successful. If it is not, even if you are outstanding at your job, you will be associated with that failure.
The best thing to do, in my experience, is to keep a watchful eye right from the beginning of a project. Usually, when a project kicks off, everyone is happy and energized and there seems to be agreement and understanding about the direction of the project, the cost, the deliverables, and so on. As time passes, however, problems inevitably creep in. You may have some small technical delivery problem, perhaps the performance of the database is not as expected or perhaps you can't handle the traffic. All of a sudden, something that could have been handled easily had the telltale indicators of project failure been looked at, is now compounded in a big mess that seems impossible to unravel.
So what are those indicators and how can we make sure to keep a project on track?
First of all, it is vital to maintain the vision and scope of a project. Vision and scope must be agreed on at the outset of a project, along with what is required to deliver on that vision. Without this, there will be an inevitable disconnect between what you are expected to deliver and what your team actually ends up building. Whenever reality starts to diverge from the vision, it is critical to reset it and bring it back in line so that what your manager expects, what your user base envisions, and what you end up delivering are in lockstep.
To make sure this happens, I have found it useful to have a document that is kept updated at all times that speaks to the high-level business objectives, that spells out the needs and requirements of all stakeholders and the interactions among them. By keeping this document always up-to-date and by sharing it and getting both consensus and approval across the board, you at least minimize the risk of encountering that disconnect between the requests your manager or other stakeholder will make and the expectations of your user base. This will also prevent the team from starting a project when they have only a superficial understanding of the project vision. One thing to note is that a vision document is not a scope document. The scope document is what is generated by the program manager or the team to align the vision to the details of a particular project.
This brings us to the next very important part of ensuring a successful project—understanding the scope of the project and making sure everyone else understands it as well. There should be a series of meetings of all interested parties that result in consensus regarding the scope of the project. There are lots of ways to assess the scope and I will not go into detail here, but one common mistake is to underestimate the effort required to meet the more complex technical challenges. Many of us are by nature optimistic, so try to keep that in mind when determining the effort required to build the solution.
Of course, there are lots of unknowns at this stage of the project and it will be necessary to make some assumptions. It is incredibly important to document these assumptions and to agree on the impact they will have on the project. Negotiating the details may also provide also early warnings of potential disconnects among people in interpreting the vision document. If two people, for instance, disagree about the time and effort involved, it is very likely they are reading and interpreting the vision document in completely different ways, and it is a signal that you might want to make sure the vision is clear enough that stakeholders all think of the same elements in the same terms.
This documentation of assumptions is critical because it provides a framework for discussing many of the nontechnical challenges with both upper management and stakeholders and will help make sure everyone understands the constrains needed to work within to deliver a successful project. Overall, exploit this document as a tool to spark the difficult but necessary conversations about scope with your management chain, and use it in order to translate some of the early concerns into answers that will help anchor your scope. Without it, many of the conversation will not happen.
Once that is out of the way, you'll have to choose the proper methodology for going forward with your project. There are lots of different models out there and all have pros and cons. There isn't one model that will always work, and choosing the wrong model can potentially spell doom for your project. Many companies have some accepted approach that is expected to be followed but is often resisted because it is too restrictive or is not "perfect" for the project at hand. But this model is important because, if tailored well, it will enable a set of gates and checks that will maintain the connection among all stakeholders. You will be able to keep your manager involved, thus preventing the chain of command from making uninformed decisions because they will feel they are part of the process with dedicated moments for providing feedback.
In fact, you should build into the process very well defined periodic walkthroughs designed to make sure that everyone involved has a chance to compare their expectations of the project against the reality of what is being delivered. This allows problems to surface and be resolved at regular intervals, with fewer ramifications.
Transparency is also critical in this phase. Any artifacts that have been generated should be shared and made available for everyone to review, giving everyone involved the opportunity to familiarize themselves, at their pace, with how things are progressing and to review the progress on their own terms. Transparency will build trust and trust is what will prevent anyone from trying to micromanage the project because they don't have access to what your team is doing. Lack of access tends to foster suspicion, and since many people don't like not knowing what will happen tomorrow, they will try to find that information for themselves. If the information is readily available, they will not have to come to you so often.
Remember also that every project will at some point need to undertake some course corrections. This should be done sooner rather than later because the more you build upon the wrong assumption, the more you will have to fix later and the harder that will be. As you go through these changes, remember to follow the same process that took you here. Start by asking all of the stakeholders if the vision for the project is the same or if it has changed, then correct the documents you have created, fix the estimates, and adjust the assumptions you had to make. Don't deviate from this process even if the decision or the course change seems small, because lots of small changes will eventually lead you to a completely different place and if you have not taken the time to document them and to maintain the communication among all the people involved, you will deliver something that, even if it is technically accurate, might not be perceived as a success.
Alessandro Muti is the CTO of Ascentium, a full service interactive digital agency and technology consulting company. He has been in the software industry for the past 20 years, starting his career at Microsoft in the Windows team. He now oversees the technical strategic direction for Ascentium and helps customers to formulate their technology strategies around digital presence, privacy, social media, mobility, security, online media delivery, digital brand management, and whatever else might even remotely look like technology.