Project:<project name>

Project Documentation and Paperwork.

We believes in keeping absolute transparency in the entire collaboration cycle with the Clients and tries its best to communicate information to the client on time and in a very easy to understand format. The formats are designed to keep the task of defining the Requirements and Deliverables very clear with emphasis on Time Schedule and People involved.

Below are few sample documents used to document projects and communicate with clients.

Project:<project name>
Code : <project code>

Task Description
T01.01. Gather Information

Assigned to : *<names of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
You will have to gather information to get a good picture of the environment, the context, the organization for which the project will be build. You will have to understand the problems, needs, opportunities of the organization. You will also have to understand how the problems and needs are likely to evolve. Then you will have to conceive a solution for to these needs and defend it. You will have to understand the consequences of the solution, its costs, risks and return of investment. You will have to estimate the size, risk, duration of the project and the necessary resources to build the IS.
Therefore, you need to gather information.

Prerequisites:
Access to information sources.

Sources:
No project documents are relevant.

Persons to Contact/Contacted :
<name, title, phone, e-mail>
<Probably the CIO, CFO, client's representative, user's representative, department's head, services, Information manager, EDP manager, IT department>

Methods, Tools, Programming Languages:
Not applicable.

Products:
Not applicable.

Tasks

Gather only those documents which are necessarily to perform the next steps of the SDLC. Though gathering some more is lesser harmful than gathering too few. Gathering information will become a background activity anyway and will serve later steps in the SDLC.

Contact the principal or client. He can offer you his cooperation and provide you with more information, or he can bring you in contact with people and make sure they will cooperate.
Gather information about the procedure for starting up a project in the organization, e.g. submission of candidate project, and project registration procedures. This includes templates of documents, required content of the different documents, delays, presentation of alternatives, costs, detail of budgets. This information will determine the next steps in the project.
Collect the names, titles, functions, phone numbers and e-mails addresses. They will be accessible to the (future) project team.
Contact the heads of departments to get their cooperation.
Find information sources and list them. This list will be useful for the project manager now and for the analyst later.
Organize the gathered documentation.
Gather information about

the organization

departments
services
managers
different policies and strategies
business strategies, tactics, rules
future plans of the company
company's information plan, automation plan or strategy and the IT policy
documentation of other information systems
procedures

existing problems
needed, desired and requested changes
triggers of these changes
Strong points of actual organization, systems or procedures.
available resources :

budgets
resources
people, their knowledge and skills
available knowledge and skills in the company
time
computer resources
hardware
network
infrastructure
offices
software and tools in use in the company
Other...

Find out about the way of working of the management. This can be important to make some points clear from the beginning or not to give bad habits a chance.
Find out if the project is a one shot, a project which won't evolve, or will it evolve or even have the role of a foundation. This is particularly interesting to know if you have to defend the project.
If the future IS likely to contain
1) valuable information which isn't present yet and is it interesting to the business, a possible expansion or to future strategies
2) information which is at the base of the activities of the organization
3) referential information valuable in different departments of the organization
it can serve (later) as a fundament for other information systems. This is a very important fact in the conception of the IS!!
The evaluation of the importance and the new opportunities the project creates are also important facts.

1. It will give arguments in favor of the project to get more resources.

2. You can imagine future use and spend some extra attention to some characteristics to ensure future developments.

3. You can better estimates changes before they happen. Think on building in a flexible, modular, generic and extensible way.

Do a first quick evaluation about the feasibility of the project.

0. Is it technically possible?

1. What are the resources which are necessary?

2. Are those resources available (time, people, knowledge, data,)?

3. What is missing and what must be acquired?

4. Can this be acquired?

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.02. First Inspection of the Organization's Problem

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The gathered information must be analyzed on a very broad level. The goal is to understand the present organization and situation, its strength and weaknesses, to identify possible improvements and thus changes and their nature. The importance of the project must become clear.

Prerequisites:
No prerequisites.

Sources :
Information Planning
Automation Plan/Strategy
IT Policy
Project Scope (if received from the principal)
Project Mission (if received from the principal)

Persons to Contact/Contacted :
<name, title, phone, e-mail>
<Probably the CIO, CFO, client's representative, user's representative, department's head, services,>

Methods, Tools, Programming Languages:
M: The Problem Solving Method PAST.
M: PIECES

Products :
Doc: <Organization's Problem Evaluation>

Tasks

The document "Organization's Problem Evaluation" contains a good framework for this task and subsequent tasks. But remember that the tasks listed here have to be performed at a very broad level.

If you received a "Project Scope" and/or "Project Mission" from the principal study not only within the defined frame but also a little bit beyond the borders to get a broader understanding.

Start a business address book commonly available to the project.
Get an overall view of the structure of the organization.
Get an overall view of the functions of the organization.
Get an overall view of the functioning of the organization.
Get a good understanding of the context which triggered the project. The project can be triggered by four kinds of problems :

1. problems with the use of existing systems	User and/or IT People
2. problems with the evolution of existing systems	IT People
3. present needs which are not fulfilled	Operational managers and maybe users
4. future needs which are expected and/or planned	Higher management

The right column indicates the people who will first be aware of the problem. They will have to be interviewed more in depth. But high likely problems will occur in all of the four categories. Use PIECES
Consult business future business plans, strategies, expectations of evolution,
Consult the company's information plan, the automation plan and IT policy. Here you will find very valuable information. Those plans may describe strategies which have to be followed or situations which can differ from the present one. Some of these differences can be candidate problems to include in the project. To increase the value of the project it is advised that the proposed solutions for the project should follow the directives and tendencies stipulated in these three guides. The project can already implement or support planned features or creates opportunities for them. This will provide essential arguments to convince about the importance of the project.
Describe the present situation with its strengths and weaknesses. When thinking on changes, make sure to keep the present strengths. At this stage, it is not a full study, but complains can be discovered through interviews of different workers and managers. Continue to use the PIECES checklist to classify the types of problems.
Start to deduce the requirements and their implications. Classify them as necessary requirement, imposed requirement or preference. Evaluate their benefits as very important, important, interesting, of low interest, no benefit and cost. Mention if they are located organizational, business procedures, business logic, business rules, object logic, technical..., Mention their domain field.
Start also to list the constraints. Classify them as real constraint, imposed constraint and preference. Evaluate the constraint the consequence of the limitation or weight on the future solution. Mention if they are located organizational, business procedures, business logic, business rules, object logic, technical...Mention their domain field.
Imagine and describe one or more situations which match the requirements and constraints. Respect the information plan, automation plan, IT policy, business goals and strategies.
Evaluate the good and bad consequences of these desired situations. Some points are : amount of work, training, new environment, new hardware, new programs, changed procedures, motivation of employees, availability of information, quality of information, new knowledge and skills, introduction of new technologies, ...
Find out what must be changed to meet the requirements.
Find out what can be changed or improved.
Map the differences between the present situation and each of the desired situations.
Group the changes. Some changes will have to be a tackled in the project; some are interesting to be included in the project, while others can be kept for other projects. This can be interesting when negotiating the content of the project accordingly to the resources.
Determine the resources and their availability. (Hardware, network, people, time, knowledge and skills, information, other systems, methods, time, finances,) They can if necessary be used as arguments.
Determine the possibilities the existing systems and organization may offer.
Elaborate the different paths to go from the present situation to each of the desired situations.
Determine if the changes have an impact on the size or functioning of the organization. In that case the help of professionals in organizational development can be useful.
Verify that the changes kept the present strengths.
Verify the requirements against the changes.
Verify the relation between the changes and systems (does one change not imply a change somewhere else?).
Verify the requirements and changes against the information plan and business strategy.
Do a first quick evaluation about the feasibility of the project.
Is the project feasible in time?
Does the company have enough resources? (Time, money, knowledge, skills,)
Is it technical possible?
Is it feasible from an organizational point of view?
If the answer is clearly 'NO', modify the 'scope', talks with the principal, or cancel the initiation of the project.
Edit the document "Organization's Problem Evaluation". This document will evolve a lot.
If you received the "Project Mission" and or "Project Scope" from the principal, check your findings with the mission.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.03. Submit the Candidate Project

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The project must be presented and submitted to <CIO, the commission x, the board x> where its importance will be evaluated. A priority will be assigned to the project. The project can then start or be put on a waiting list. The presentation of the project must reflect the right importance of the project.

Prerequisites:
no prerequisites.

Sources :
Information Planning
Automation Plan/Strategy
IT Policy
Project Scope (if received from the principal)
Project Mission (if received from the principal)
Organization's Problem Evaluation

Persons to Contact/Contacted :
-

Methods, Tools, Programming Languages :
Not applicable

Products :
Doc: Candidate Project Submission

Tasks

Inform about the existence of standard procedures, usual way of doing or document templates used for the presentation of a candidate project. This will give you an idea if the presentation of the project should be short or very complete.
Gather all the arguments which emphasize the importance of the project.
Prepare the submission paper of the project.
Gather advice and opinions. (Always useful).
It can be handy to check how members of the steering committee feel about the project and to start to interest them for the project by having a talk with them individually before presenting the project.
Verify the document. Let other team members check the document.
Submit the document.
Get the approval.
Get the execution information like date, budgets, assigned people,

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.04. Register the Project

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The registration of the project is necessary to make the project officially authorized, known and accepted. This is important for the different business units the project team will have contacts and to cooperate with. The registration is also important to the accountancy to record the costs.

Prerequisites:
No prerequisites.

Sources :
Candidate Project Submission

Persons to Contact/Contacted :
<name, title, phone, e-mail>
Probably the CIO, CFO, CEO, client's representative, user's representative,

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: Project Registration

Tasks

It's an excellent opportunity to measure the motivation, to make contacts and try to obtain cooperation. Try to say include other people by make and allusion on probable future rendezvous and cooperation.

Gather information about the organization
Inform about existing project registration procedure. Else find out how to register a project.
Inform about who has to sign to register a project. Be sure to gather correct information.
Edit the Project Registration document.
Submit and get the confirmation of the Project Registration. One of the elements of information is a code of the accountancy. Each budget reservation or cost declaration will be assigned to this code.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately

Project:<project name>
Code : <project code>

Task Description
T01.05. Make the Project Initiation Plan

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The Project Initiation Plan provides a guidance of the activities of the first phase "Project Initiation - Feasibility Analysis" and the second phase "Project Definition" until the Project Plan is established. It promotes a common view about the project and about what has to be done. It is a way to communicate with the stakeholders. By protecting the project from unforeseen requests or activities it leads the activities more efficiently to the goal. If a change has to be taken into account, it will be easier to notice it by comparison to the plan and to react adequately.

Prerequisites:
No prerequisites.

Sources :
Information Planning
Automation Plan/Strategy
IT Policy
Project Scope (if received from the principal)
Project Mission (if received from the principal)
Organization's Problem Evaluation
Candidate Project Submission
Project Registration

Persons to Contact/Contacted :
<name, title, phone, e-mail>
Probably the CIO, CFO, CEO, client's representative, user's representative,

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: Project Initiation Plan

Tasks

Make a list of the stakeholders who will have to be contacted to perform the two first phases of the project.
Evaluate what will be their role in the information system.
Evaluate what will be their contribution during those two phases.
Define the tasks which have to be done until the end of phase 2.
Select the tasks which have to be performed describe and order them.
Evaluate the size of the project.
Evaluate the resources needed to perform the two first phases.
Distribute the tasks and responsibilities to the team members.
If team members are already available, discuss the matter with them.
Make a rough schedule of the tasks.
Inform about how to report progress and problems to the principal.
Inform about how to react in case of changes in the Project Initiation Plan.
Inform about the way of canceling projects.
Gather financial information
Make a rough budget plan.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately

Project:<project name>
Code : <project code>

Task Description
T01.06. Approval Project Initiation Plan

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The approval of the Project Initiation Plan. This is a global agreement between all the concerned parties. It freezes the first version.

Prerequisites:
No prerequisites.

Sources :
Project Scope (if received from the principal)
Project Mission (if received from the principal)
Organization's Problem Evaluation
Candidate Project Submission
Project Registration

Persons to Contact/Contacted :
<name, title, phone, e-mail>
Probably the CIO, CFO, CEO, client's representative, user's representative,

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: Project Initiation Plan

Tasks

Who has to approve the Project Initiation Plan?
Within which delay must it be approved?
What to do in case of refuse?
Verify the Project Initiation Plan
Submit the Project Initiation Plan

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.07. Prepare the Project Mission

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The Project Mission describes at a very high level the mission which is expected to be performed. The Project Mission is an essential document because it sets the goals, priorities, limits, responsibilities, authority and so on.

Prerequisites:
No prerequisites.

Persons to Contact/Contacted :
<name, title, phone, e-mail>
-

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: Project Mission Doc: Project Scope

Tasks

P>Important Note:
Usually the higher management (IT manager, CIO, EDP manager,) or principal delivers the mission statement. In this case it is advisable to verify if the mission statement is complete, if it reflects with the situation like it really is, and if it is the best way to handle. An analysis may discover other opportunities or barriers. They should be discussed with the principal.
Verify also the completeness of the Project Mission.

Capture the most important points correctly. These points are often global business functions, points which will influence the core architecture, the choice of technologies, the required knowledge and biggest changes.

Describe the context of the project. This is a brief description of the current way of working, the organizations and systems which are in contact with it, the services which are used or provided.

Describe the needs, problems and requirements. Limit the list to the main points.

Describe the goals.

List the objectives necessary to reach the goals. Try to quantify them.

List the business functions which will be improved or automated. Mention, still at a high level, how the business functions will look like after the changes.

Enumerate the kinds of information which will change and describe the change. (E.g. client information’s will be expanded; orders will be linked with stock information,).

List the organizational units which will be involved in the changes and what will the contribution, cooperation or change look be like.

List the information systems which will function as source of information, service provider, to which information will be passed or services delivered. Here also, describe the kinds of participation of the systems or how they will be changed. Mention not only names of systems, but also their role.

List as many actors as possible. You can classify them as user, information provider, information receiver, service provider, service receiver. You may specify the roles more in details, but don't be too detailed.

Describe the requirements.

Describe the responsibilities the project team and project manager have to the principal or user's management.

Describe the authority which is needed to lead the project. This consists of things like independence of the project from the user's management, the ability to obtain cooperation or to have access to some documents, the ability to introduce changes in the organization (this must be detailed), authority over persons which do normally not belong to the 'project hierarchy', and all kinds of other authorities.

Describe the resources at the disposal of the project. This doesn't mean that these resources will be used, neither that no more resources will be asked.

Describe the deliverables.

Describe a global and roughly estimated timeframe. In the document mention the fact that this is a very premature and rough time estimation which serves only as guideline but is not binding.

Describe the mission. The mission is a summary of the previously mentioned points.

Discuss different the options with the team.

Check for how the team interprets the document.

Verify the completeness, level of detail, ambiguities, mention of right priorities, etc...

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.08. Interview the User's Management

Assigned to : *<names of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal :
The interview of the higher management has several goals.
1. To get a contact and facilitate cooperation
2. To verify the mission
3. To get a picture of priorities

Prerequisites:
No prerequisites.

Sources :
Information Plan
Automation Plan/Strategy
IT Policy
Organization's Problem Evaluation
Candidate Project Submission
User's Organization Description
(Project Mission)
(Project Scope)
Project Initiation Plan

Persons to Contact/Contacted :
<name, title, phone, e-mail>
managers of the user's organization

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: Project Scope Doc: Project Mission

Tasks

Prepare the subjects to talk about. Use therefore information of previous activities. The goal is to understand the vision of the management about the following points :

Opinion about the mission, objectives, strategies and CSF's of the whole company.
Opinion about the mission, objectives, strategies and CSF's of the organizational unit he is responsible for.
how do the previous two points fit together
opinion about the priorities of the objectives
opinion about the future of the company
opinion about the information needs within the organization and his organizational unit
the influence of the project, and more broadly IT within the evolution of the organization

Choose as interview technique for open questions. Pay attention on the arguments of manager and on how he judges situations.

Analyze the results. Understand the differences between the picture you had before the interviews and after. Understand the differences between the different opinions of the managers. Judge if the interviews contain some indicators for potential problems. Readjust the priorities. Update, if you have the authority, the project mission and project scope. Else, if necessary, talk about your findings to the principal or user's management.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.09. Approval Project Mission

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
This task is only useful if not yet performed or if the feasibility made some changes necessary. The approval of the adapted project mission and scope goes together with the feasibility analysis. This approval will make the objective more and more stable.

Prerequisites:
No prerequisites.

Sources :
Project Initiation Plan
-

Persons to Contact/Contacted :
<name, title, phone, e-mail>
Probably the CIO, CFO, CEO, client's representative, user's representatives,

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: Project Mission / Scope

Tasks

Who has to approve the Project Mission / Scope?
Within which delay must it be approved?
What to do in case of refuse?
It can be handy to check how members of the steering committee feel about the project and to start to interest them for the project by having a talk with them individually before presenting the different solutions.
Let other team members check the document.
Verify the Project Mission / Scope
Submit the Project Mission / Scope
Get the approval.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.10. Analyze the User's Organization

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The previous activities are meant to launch the project and to set the target.
The following activities are much more oriented to analyze the situation to get a global picture of the problems and needs and about the nature and size of the solutions.

In order to build an information system which serves the purposes of the organization, we need to understand how this organization works. Some risks in IS development may come from the organization. At this stage this investigation is still quite limited to essential points.
Actually, this task is already a part of the 'Feasibility Analysis'.

Prerequisites:
No prerequisites.

Sources :
Information Planning
Automation Plan/Strategy
IT Policy
Project Scope (if received from the principal)
Project Mission (if received from the principal)
Project Initiation Plan
Organization's Problem Evaluation

Persons to Contact/Contacted :
<name, title, phone, e-mail>
User's representative, to specify.

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: User's Organization Description

Tasks

Don't loose the project mission and scope out of sight. They determine the work domain. Of course, investigating also beyond the borders mentioned in the project mission will provide you a better understanding. Though, keep the domain mentioned in the project scope in the center.

Study the following points of the organizational units close to the project :

hierarchical structure
goals
responsibilities
roles
domains of knowledge
functions
tasks
events to which the unit responds
priorities
policies
future evolution
amount of work
relations and interfaces between other organizational units
used information systems
information flow (DFD)
geographical location

Try to discover possible problems in the organization which might affect the project.
These risks can be :

unassigned responsibilities
overlapping responsibilities (doubly assigned)
unclear function attribution
same persons have different roles
work under pressure
unclear role and responsibilities assignment
lack of knowledge, understanding, experience and capabilities to perform a job
inefficient workers
inefficient management
lack of knowledge and understanding of IT or a wrong picture of IT
lack of knowledge and understanding in the business
lack of goals and strategies
lack of planning
continuously changing decisions
inadequate or incomplete procedures
Management which is not in balance, e.g. it is disconnected from the base and/or reality, meddles only with little activities, spend only effort in control or only in planning,
conflicting interests
conflicting policies
wrong or ever changing priorities
lack of information
lack of resources
conflicts between people
lack of or unclear business rules
lack of motivation
lack of authority of the IT in the organization
sabotage
tensions due to lack of job security
resistance for change (habits, fear, lack of flexibility)
sub-units optimize own goals, not larger goals
sub-cultures and fragmentation (chimneys)

It is not of the responsibility of the software development team to solve those problems. But it is in the general interest that they do not persist.
Take about it to the person(s) or to the concerned manager. Advise employees to speak about it to their manager, to search for other professional help or a mediator, or to find a solution.
Evaluate the consequences for the project if they persist.
Evaluate the risk and the seriousness of the impact.
Find solutions and work-around.
Report the problems to the principal or user's management.
Reevaluate the mission statement and scope. If any problem arises discuss it with the principal or user's management.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.11. Define the Problem

Assigned to : *<name of the analyst>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
After we learned the organization and its problems and needs, we have to understand their problems and needs in a more practical way. This knowledge will allow us to conceive the architecture of a solution, a division in sub-projects if necessary, to have a clear idea of the opportunities, size of the project and needed resources. The goal of this activity is to allow us to understand the problems.

Prerequisites:
no prerequisites.

Sources :
Information Plan
Automation Plan/Strategy
IT Policy
Project Scope
Project Mission
Project Initiation Plan
Organization's Problem Evaluation
User's Organization Description

Persons to Contact/Contacted :
principal, users, user's management

Methods, Tools, Programming Languages :

Products :
-

Tasks :

Consult business future business plans, strategies, expectations of evolution,
Consult the company's information plan, the automation plan and IT policy. Here you will find very valuable information. Maybe you will discover here that they differ with the present situation. Some of these differences can be candidate problems to include in the project. To increase the value of the project it is advised that the proposed solutions for the project should follow the directives and tendencies stipulated in these three guides. It can already implement or support planned features or creates opportunities for them. Acting like this will provide essential arguments to convince about the importance of the project.
Analyze the User's Organization.
Analyze the present information systems.
Describe the present situation as a whole.
Interview people and listen to their opinions, evaluations, complains, present and future needs and wishes.
Get a good understanding of the context which triggered the project.
Identify, list and analyze the problems, opportunities for improvements and required changes. Evaluate their importance.
Deduce and list and define the requirements and their implications. Classify them as necessary requirement, imposed requirement or preference. Evaluate their benefits as very important, important, interesting, of low interest, no benefit and cost. Mention if they are located organizational, business procedures, business logic, business rules, object logic, technical..., Mention their domain field.
List all the constraints. Classify them as real constraint, imposed constraint and preference. Evaluate the constraint the consequence of the limitation or weight on the future solution. Mention if they are located organizational, business procedures, business logic, business rules, object logic, technical...Mention their domain field.
Identify and map the changes. Mention their nature impact and size.
Discuss different the options with the team.
Check if, accordingly to the global picture, the project mission and scope are still valid.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.12. List the Available Resources

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The list of available resources will be of great help when designing a solution.

Prerequisites:
no prerequisites.

Sources :
Project Registration
Project Mission
Project Scope
User's Organization Description

Persons to Contact/Contacted :
user's representatives, user's management,

Methods, Tools, Programming Languages :
-

Products :
List of Available Resources

Tasks :

When listing the resources mention, if possible, also the amount period of availability, the quality, price, or other conditions. Mention also the resources which are quite easily to acquire. It can be useful to add the resources which are essential and which are harder to acquire.

Enumerate the information sources
Enumerate the information systems
Enumerate the software, libraries, tools
Enumerate the hardware resources like servers, workstations, network computers, network resources, back-up system and other hardware.
Enumerate the available knowledge, skills and experience.
Enumerate the available people.
Enumerate the financial and time resources.
Enumerate the other resources.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Project:<project name>
Code : <project code>

Task Description
T01.13. Conceive a Preliminary Solution

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
After we learned the organization and its problems and needs, we have to understand their problems and needs in a more practical way. This knowledge will allow us to see how the existing architecture is adapted and/or extended, to conceive one or more preliminary solutions at a very high level within the architecture to have. This will also give an ides about the need and the way to divide the project into sub-projects and a clearer idea of the opportunities, size of the project and needed resources. The picture is still global and will become more precise later in the project.

Prerequisites:
no prerequisites.

Sources :
Information Plan
Automation Plan/Strategy
IT Policy
Project Mission
Project Scope
Project Initiation Plan
Organization's Problem Evaluation
User's Organization Description
List of Available Resources

Persons to Contact/Contacted :
user's representatives, user's management,

Methods, Tools, Programming Languages :

Products :

Tasks :

Try to build with and upon the existing architecture. If a change is foreseen or inevitable, follow smoothly this evolution. Keep the architecture open. Respect the limits in amount of resources. Design the efficient solutions. Try to use as much as possible technologies which will last, which are broad and complete and which are or will be chosen as future technologies in the company. Limit the number of chosen technologies in order to keep the project simple and to avoid interoperability problems or problems in the cooperation of the technologies. Choose proven and stable technologies. Open your eyes to new, unusual and unknown technologies.

Determine the possibilities the existing systems and organization may offer.
Determine which resources can be used for which changes.
Elaborate the different paths to go from the present situation to each of the desired situations.
Conceive different technical solutions. Use help of people who master the technical field, products and technologies. Don't loose the information plan, automation plan or strategy and the IT policy out of sight.
Verify that they are technically and practically well conceived.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.

Code : <project code>

Task Description
T01.14. Make the Feasibility Analysis

Assigned to : *<name of the analyst>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The Feasibility Analysis will tell us if the planned development is realistic. We expand the term "Feasibility Analysis" to a broader sense. The Feasibility Analysis consists of :

Technically feasible
Organizational feasible
Feasible given the available resources
Economically justified

Prerequisites:
no prerequisites.

Sources :
Information Plan
Automation Plan/Strategy
IT Policy
Project Scope
Project Mission
Project Initiation Plan
Organization's Problem Evaluation
User's Organization Description

Persons to Contact/Contacted :
-

Methods, Tools, Programming Languages :

Products :
Doc: Feasibility Analysis

Tasks :

The Feasibility Analysis is a one shot-document. The easiest way to handle is to verify and update the previous documents. Then to gather the necessary information from those documents to put it in the document "Feasibility Analysis".

The documents which have been made until now are merely documents designated to the management (reports), and lesser working documents. Depending on the size of the project, it can be interesting to separate the following topics information in different documents.

User's Organization
Information Systems (one document per IS)
Objectives, problems, requirements and constraints
Global Survey of the Present Situation (Relation between the three precedent topics)
List of available resources
The Feasibility Analysis

The steps to perform are :

Inform about the existence of standard procedures, usual way of doing or document templates used for the feasibility analysis of a project. This will give you an idea if the presented feasibility analysis should be short or very complete.
Describe for each solution :

the description of the solution
the strengths
the weaknesses
the benefits
the opportunities
the changes (obliged, not obliged but useful and additional)
the steps to build the solution
the dependencies
the critical success factors
the needed and costs in resources (time and money)

If one solution presents itself as technically the best, you can mention other solutions, but continue with this one. Discuss the choice with other experts. But be prudent. There are a lot of other factors which do not belong to the IT which can change the decision. These are factors like: changes in the organization, finances, future changes in business, and so on.
Evaluate the technical feasibility of each solution. Interoperability, compatibility, performances, limits, stability.
Evaluate the required resources. Are the resources in-house? Are they easily to acquire? Are they available on the market? Is the hardware available? If new resources must be acquired, will its management and maintenance be possible and is this supplementary cost acceptable? How about servers, networks, back-up systems, work of operators, time during which batch programs can run, people to maintain the future system, etc..
Evaluate the impact in matter of changes in the organization. Do we have the authority to force changes in the organization? Is it acceptable? Do people agree with it? What will be the risks and problems if such changes are required?
Evaluate the expected return of investment.
Choose one solution and suggest it.
Prepare the submission paper of the project.
Gather advice and opinions. (Always useful).
It can be handy to check how members of the steering committee feel about the project and to start to interest them for the project by having a talk with them individually before presenting the different solutions.
Verify the document. Let other team members check the document.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.
- If you notice an influence on a module, on someone else work, notify it immediately.

Project:<project name>
Code : <project code>

Task Description
T01.15. Approval Feasibility Analysis

Assigned to : *<name of project manager>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
A study of the current situation has been made. Solutions has been conceived and evaluated. The approval of the Feasibility Analysis confirms the choices which have been made.

Prerequisites:
No prerequisites.

Sources :
-

Persons to Contact/Contacted :
<name, title, phone, e-mail>
Probably the CIO, CFO, CEO, client's representative, user's representatives,

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: Feasibility Analysis

Tasks

Who has to make choices in the proposed solutions?
Who has to approve the Feasibility Analysis?
Within which delay must it be approved?
What to do in case of refuse?
It can be handy to check how members of the steering committee feel about the project and to start to interest them for the project by having a talk with them individually before presenting the different solutions.
Verify the Feasibility Analysis.
Let other team members check the document.
Submit the Feasibility Analysis.
Get the approval.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately

Project:<project name>
Code : <project code>

Task Description
T01.16. Close the Project Initiation Phase

Assigned to : *<names>*
Planned : from	<date>	to	<date>	# of days	<n>
Execution : from	<date>	to	<date>	# of days	<n>
Delay of Start	: <n days>	Delta Execution Time	<+/-n>
Verified by <name>???		on	<date>
Notes :

Goal:
The goal is to report the evolution of the project, evaluate the present situation and the continuation and to mediate how to improve this phase a next time.

Prerequisites:
No prerequisites.

Sources :
-

Persons to Contact/Contacted :
<name, title, phone, e-mail>
team members

Methods, Tools, Programming Languages:
Not applicable.

Products :
Doc: Report Phase 1 : Project Initiation and Feasibility Analysis

Tasks

Make a list of the unsolved problems. Discuss it with the team members. Find out why they occur, their consequences and how to prevent them. Evaluate if they have to be solved now or later, by whom, or if they should be reported.
Identify mistakes in the execution of the phase. Find out why it occurred, how to prevent it, how to react. Find out how to improve this phase a next time.
Verify the further planned execution of the project. Is it still feasible and realistic?
Report the progress of the project.

Additional note:
- Take note of all problems.
- If the execution of the task does not match with the described approach, adapt the documents immediately.