Project planning

If you are reading this book with the intention of building an IT business solution for your company, then you are probably already involved in a project or some type of initiative with clear objectives and metrics in order to achieve success. Every successful IT project requires a great bit of attention to detail in planning and architecting a solution that would have a substantially positive impact on business operations. Many consulting companies take a phased approach when working with their client on projects. Usually, a project manager creates a project plan with a schedule chalked out to complete tasks or milestones. Projects can vary in terms of size and resources. On a very basic level, the lifespan of a project can consist of several phases:

• Design
  • Conducting the analysis of an existing environment
  • Defining business requirements and limitations
  • Architecting an IT solution according to specifications
• Implementation
  • Building a solution based on design specifications
  • Documenting an environment and all the steps involved in deployment
• Testing and piloting
  • Forming a test group of users to participate in a pilot
  • Receiving and reporting feedback
  • Resolving issues discovered during the pilot phase
• Go-live
  • Requesting a maintenance window via change control
  • Ensuring visibility within an organization
  • Bringing systems online
• Post-implementation knowledge transfer and support

During the design phase, architects usually study the existing environment and collect data to plan the steps needed to accomplish the goal of a customer. During this time, they gather requirements from stakeholders (management, IT, users, and service providers) and define any limitations that may present themselves during the deployment. For example, an application that runs on a 32-bit OS can be challenging to implement on a 64-bit OS and will be defined as a limitation. Another type of limitation is a company's financial budget. A project can only be completed successfully if the company can afford the necessary software, hardware, and professional services involved in the implementation. Once sufficient data has been gathered and clear goals and limitations have been set, the architect can begin designing the new environment with the desired results in mind.

After the design is completed and has been cleared and a detailed reference architecture exists, the next phase of the project is to implement the system that was designed. Multiple resources can be involved in the implementation, including solution architects, systems engineers, support engineers, and others. The key focus during implementation is to execute the project plan within the deadline defined by the business and to ensure that all milestones are met and documented properly.

Once the environment is deployed, it can be placed into a pilot where a relatively small user group is designated for testing, and vital feedback on functionality and performance is collected from users. The goal of testing is to report and mitigate any issues in the environment and ensure that performance of the newly deployed system is acceptable for the business.

If all issues are properly resolved and users validate good performance and functional levels, the environment can be rolled into production. In enterprise operations, production is a frequently used jargon to describe actively used systems that are critical to the well being of the company. There is an inherent sense of caution and urgency whenever production is discussed and all IT resources are mobilized during the go-live process to ensure that rollout of the systems is successful and if there is an issue, a rollback plan should be in place and ready to be executed.

Once the new environment is online and users start doing their day-to-day activities on it, the project can be concluded and post-implementation support begins.

In this section, we've only described one of many ways a project can be rolled out. The scope of such an engagement largely depends on the company, technology, and the parties involved. For example, a government agency will have project guidelines that are very different from those of a private sector company due to compliance standards applicable specifically to public institutions. Some phases will also vary based on the type of solution being deployed and its impact on business operations. Replacing a core switch, for instance, would most likely require downtime that would affect a large number of users, while updating QuickBooks would only affect the accounting department. These are factors that must be carefully evaluated during the design phase.