Project Management: Planning Phase. Functional & Technical Designs

I would like to start detailed description for the Project Planning Phase with Functional and Technical designs. As I’m speaking about software development projects, this post will have some specific, and of course you cannot use the same templates for example building projects ))).

Another important thing is that designs are normally does not created by Project Manager – we have determined analysts on Initiation phase and design development would be their task. Usually analyst on business side (business itself or product manager in the project team) develops functional specification and technical architect or technical lead is responsible for technical design.

Based on my practice I recommend starting design development ASAP. The main reason is that these documents are the most complex and large among all other documentation created during Planning Phase. It’s usually takes a lot of time to create them, also we need some time for approving them. Also these documents are base for other activities:

  • You cannot start detailed project planning without full list of tasks with baseline hours. And this list can be created only when technical design is completed.
  • You cannot determine the project team, as you do not know what technologies are planning to be used during the project, so you do not know what kind of specialist you are required. This information is also contained in technical design.
  • And you cannot start real work on technical design while not all user requirements are collected. This work is done while functional specification development.
  • Of course costs and risks are also closely linked with these documents.

To sum up, if you do not want to have real bottle neck and pauses during the detailed planning phase, start developing of this documents even on Initiation phase, do not delay this work and try to involve analysts on 100% into project on Planning Phase.

The quality of these documents is another important thing I have to say about. If you have made a mistake in the architecture and this was noticed during design agreement, it would take rather small amount of time to put some changes into the document. But imagine, what would happen if this error is identified on users test stage. I have an example when such error has caused loss of 800 hours of developers’ work and restart of the project. As a conclusion, be mindful of the time, but do not forget about the quality of the functional and technical documentation. They are the baseline for your future development.

At last let’s briefly describe each section of functional and technical designs with some comments.

Functional design

  • Introduction – this section contains context, scope, definitions, references, etc.
  • Process overview or functional model – the main section which usually varies for each project and contains requirements, process description, etc.

Technical design

  • Logical model – this section contains logical database models, users’ forms, not very technical description of the logic developer has to implement. Business or functional analyst must understand this section. Usually I try to approve it with project leads on business/customer side.
  • Physical model – this section is for developer only. Physical database structures, internal algorithms (architecture of storage registers or encryption algorithms), etc.
  • Security – this section is dedicated to user permissions for developed functionality. What new application roles must be created, who would have access to fields and buttons and who wouldn’t. Usually this section translates requirements from functional design to developers’ language, so there is no need for additional approves with customers.
  • Interfaces – this section contains description for data interfaces between informational systems. It’s usually for matching of tables/fields in one system with tables/fields in another – rather technical, for internal use only.
  • Data Edits – in this section massive one-time data uploads from external sources are described. Also for internal use.

So, that’s all I wanted to discuss about functional & technical specifications development. In the next post I would continue writing about Project Detailed Phase.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *