In this article I will present some hints to consider when starting a project, so that we will be able to avoid "unpleasant surprise" once the work will be started. We can consider some of this points in our contract or simply keep them as project risks, but surely we shouldn't ignore them.

This sequence is naturally applied when products of project are IT applications or are IT related, but in my opinion, many of the observation are good even in case of not-IT projects.

Sponsors and Stakeholder Expectations

Along the whole project duration we need to manage the expectations of our clients. However, the most critical moment in this task happens at the beginning of the project, when we are defining the roles, the project expectation, the deliverables and the project economics

• Identify as soon as possible the key sponsor, the target user and other stakeholders group. We need to have clearly closed the following list early in the project:
  
  • who pays for the project
  • who is representing the user groups
  • "internal" users - who, inside the organzation will use the product
  • "external" users - clients of the organization that interacts with the product
  • "indirect" users - these users do not interact with the product but use what the application produces
  • support groups that later will have to maintain the product
• Understand and document the goals and expectations from the sponsors and other key stakeholders
• Understand and document concerns from the sponsors and other key stakeholders, and ensure that the project has a plan to address them.
• Understand the role of each stakeholder and the influence he/she has on the project’s success.

Solution Model

Once it will be clear who our counterparts are, we need to have clear what the final product will be

• Clarify with stakeholders and sponsor what the business problem we need to solve are. Later report these ides to the project team members.
• Verify that the Solution Model has identified all the major application and technical infrastructure components that are needed by the business.
• Verify that the Solution Model has addressed the target business processes and identified the major business events that should be handled by the application.
• Verify that the Solution Model has addressed integration issues between the third-party products and other applications. We need to have really clear how the product will be integrated into the system.
• Verify that the Solution Model has identified the impact of the application on the workforce and customers, and
• Verify that hat high-level training and performance support requirements have been documented.

Scope

This is critical when considered in junction with future project evolutions and future issues with the client. This subject was already discussed also in another article (project risks).

• Discuss in detail the project scope with the Sponsors and other key stakeholders, and obtain their approval.
• Involve as much people as possible (the business architect, technical architect, integration solution architect, human performance architect, and service introduction lead) in defining the project scope.
• Ensure that the project scope covers.
  • Reporting
  • Security
  • Integration of the new application with other applications.
• Define as soon as possible a change management process to handle scope changes within the project

Estimates

Another theme usually subjected to heavy discussion is the estimation. I already discussed this in two articles about the financial of a project and in the control checklist on the quality of our estimations:

• Consider the time and expenses to select, modify, and implement any third-party products.
• Consider the effort to prepare for transitioning the application to the Application Management team.
• Consider the effort associated with working with third parties (usually communication implies an high effort).
• Consider the costs associated with training, performance support, and communications.
• Consider the costs associated with transition activities between teams, if multiple teams are used to complete various stages of the project.
• Ensure that the buying sponsor has a clear understanding of the estimates and has accepted them.

Delivery Approach

• Define the development model, releases, their scope and dependencies.
• Ensure that the sourcing approach has considered the use of different types of workforces.
• Identify and define the transition approach between teams.
• Ensure that deployment has considered both “big bang” and “incremental” approaches, both in term of organizational and scope impact.
• Consider production simulation, parallel run, release in "friendly environment" as part of the deployment approach.

Transition

A specific article will treat the transition from a development to a maintenance team. However basic points are:

• Ensure that all the documentation to be transitioned has been completed
• Ensure that the analyzet team has walked through the scope and requirements with the development team.
• Address all questions/issues on project scope and requirements.
• Ensure that the Analyze team has a clear understanding of the project scope and requirements, as well as deliverables and deadlines for which the team is responsible.
• Ensure that the Analyze team has officially accepted the transition and is ready to proceed with the analysis work