PM in our everyday life. Quick look at differences between operation and project management.

Several years ago I’ve posted a series dedicated to project management. It was quite hard, fill with technical details and not very clear for common understanding of project management. Today I would like to return to this topic but on quite another level: try to look at project management as simple thing, that can be used not only for large enterprise activities but also in our everyday life.

It’s my firm believe, that if we use project management to handle some of our outside events and activities, we can achieve much better results and have much more enjoy )))) Project management can help us to keep the goal, set priorities, track our progress and, as a result, succeed in our affairs.

First, we must understand, when we face a project. For some doings project management can help greatly, and quite on the contrary, it would lead to overload and fail being applied in wrong place. So, how to identify when we need a project approach? Below there are listed some definitions that will help us in this task.



Implement change Support current state
Has end date Ongoing operations
Team is disbanded, when project is closed Team stays together
Work is unique Work is repeatable
Budget is for project tasks and needed resources Fixed budget

The main difference:

  • Operations management is what runs the life.
  • Project management is what changes the life.

Project has defined start and end dates and we have to implement the required change or achieve desired result. When project is finished – it is closed,  and we return to our current activities.

We can find projects in different spheres, not only with professional background. Some project examples from our life:

  • Holding an event,
  • Holiday trip,
  • Birthday party,
  • Moving to a new place,
  • Birth of a child,
  • Getting education.

And you can probably think of hundreds of other examples relevant to your everyday life. Next time I will dwell on project initiation and try to create some real example for better description how it looks like.

Posted in Project Management, Project Management Everyday Life | Tagged , | Leave a comment

Common structure of IT department

I’m happy to say, that I’m back ))) Cannot promise to post weekly but will try not to disappear for years )))

Today I would like to describe IT structure in several dimensions and say several words how it operates. If you look at IT from organizational structure side – it can be presented somehow like this:


Some blocks are presented in every IT, all blocks can be outsources, some blocks are optional.

  • IT Lead – is a person that is completely responsible for how IT operates. Commonly he or she is the employee, while other IT-staff can be outsourced.
  • Help Desk – generally call center that is responsible for tickets registration from users and for solving simple tasks using standard practices and procedures. Usually they have quite wide permissions and can operate with users’ accounts. Therefore, they are the main target for social engineering, and must have good standards and regulations.
  • Filed Support – provides remote and on-site customer support and services. They are typical engineers with local admin permissions solving users’ everyday issues and problems.
  • System administrators – their field of responsibility is servers, local network, Internet, telephony.
  • Developers – support and develop local IT-systems due to business needs and requirements.

Moreover, every employee of the IT-staff can take part in Business & IT projects in different roles.

Now let’s try to picture how IT looks from user’s point of view and how tickets are proceed.


The scheme is rather simple: all user requests are passed through single window and are registered in a service desk system. Then ticket goes down from level to level until it is solved. Then user is notified that his problem was resolved and usually offered to pass through customer satisfaction survey. Thus, IT gets users’ feedback and can improve its operations.

As in previous posts I have already described in details the management of development team, this time I’m going to concentrate on two first levels of IT support: Helpdesk and Field Support.

Before going forward it’s important to say about KPI. In the future I would dwell on KPI’s, how they are handled and calculated, but today I would only name them.

Main KPI’s for common Help Desk and Filed Support services can be divided into two groups: Quality metrics and Productivity metrics.

Quality metrics include the following KPIs:

  • Time to resolve problems (SLA). The SLA is defined based on the urgency of the ticket.
  • Customer satisfaction with Help Desk.

Productivity metric is:

  • IT service availability.

It’s all for today, and in the following posts, I would continue to share my experience how to create and manage effective processes for Help Desk and Field Support groups.

Posted in IT Management | Tagged , , | Leave a comment

Project Management. Planning Phase. Costs.

In this post I will speak only about several costs’ calculations that can help us to track project expenses. I would like to put all calculation in one table and then make some comments to presented data. Also, I would dwell only on labour calculations, but it would be rather easy to expand them to any project costs.





PV (Planned Value) – hours 4 000 4 000 Amount of hours we planned for the project.
EV (Earned Value) – hours 480 960 Calculates as PV * %Completed Work. In the example – on Feb 26 we have done 12% and on March 26 – 24% from total amount of work.
AC (Actual Costs) – hours 440 900 Amount of real hours we spent till the moment.


26.02.2013 26.03.2013  
PV (Planned Value) – $ 40 000 40 000 Costs – multiplication of hours from the previous section on hours cost. To simplify calculations – I’ve taken the value $10. These labor calculations are rather useful as can be used without additional efforts in project reports.
EV (Earned Value) – $ 4 800 9 600
AC (Actual Costs) – $ 4 400 9 000
EVM Earned Value Management 26.02.2013 26.03.2013  
CV (Cost Variance) – hours 40 60 EV – AC

Shows us whether we are in budget or not. When this number is negative, that means we have spent more than has been planned. In the described case – we make some savings.

SV (Schedule Variance) – hours -3 520 -3 040 EV – PV

How many work we still have to do.

CPI (Cost Performance Index) 109% 107% EV / AC %

Is linked to CV coefficient but gives us an opportunity to make an absolute analysis of budget savings or losses. You can see that 60 is larger then 40, but in percents we are losing positions as from 109% we moved to 107%.


The main idea of the described coefficients is to signal to project manager on the very early project state, that we have some cost issues and project can miss budget targets. When CV parameter is below 0 and CPI – below 100%, it’s time to intervene and make some corrections in project management. Also, it’s usually very useful to build a chart, showing the changes of CPI.


Posted in Project Management, Software Development, Technology | Tagged , , , | 1 Comment

Project Management. Planning Phase. Schedule.

Project schedule – after creation it is used regularly till end of the project. The main schedule I prefer to track in Microsoft Project. In my practice I’m trying to use the following principles while dealing with MS Project:

  • Human resources load can not be more then 80%. On the one hand nobody can work 100% a day, on the other hand there is a small time reserve – it sometimes can help you meet deadlines.
  • All milestones and deadlines from A3 and business project request as well as key dates from risks list must be moved to MS Project as deadlines or other highlighted elements. E.g. I usually marked tasks on which critical risks depend with special colours. I can say that last versions of MS Project provide a vast variety of different design tools, so only your imagination can restrict you ))).
  • I also group tasks by development phases: design section, development section, test section and stabilization section. This helps to estimate the total amount of work for each phase of program life cycle and set logical links between each phase.
  • I try to compose tasks using the following rule: minimum task length 1 hour, maximum – 40 hours. It’s quite hard to register and analyse tasks smaller than 1 hour – such micromanagement would overload project manager. And it’s impossible to track huge tasks – you would never know exactly when the task would be ready – you can face the situation when developer has spent all 100 hours and is still at the beginning of the process. And it’s better to know about the fact we have some problems after 16 hours, then after 100 hours.

The MS Project file can look like:


But how we can communicate this plan to project sponsor and business representatives? It’s a bad idea to send them plan in MS Project – they do not need such detailed specification. For this purpose I create a separate file in MS Excel and update it on weekly or monthly basis (depends on the project duration).

This file uses also Gantt principles but much simpler than MS Project:


The vertical red line shows current week. This file is a top level schedule for the project and is rather suitable to be presented to project team.

Posted in Project Management, Software Development, Technology | Tagged , , , , | Leave a comment

Project Management. Planning Phase. Communication Plan.

Communication plan is a set of matrixes and procedures to regulate relations inside project team and with outside teams and individuals. Usually I do not publish communication plan as a separate document, it’s the part of Project Management plan.

In my post I will go through main section of communication plan, briefly describing each of them.

Responsibility Assignment Matrix

Name \ Phase Request Initiation Detailed Planning Execution & Control Closeout
Name 1 A P R    
Name 2       I S

Letters have the following meaning:

  • А – accountable for the project phase,
  • P – participant in the project phase,
  • R – review required,
  • I – input required,
  • S – sign-off required.

Distributed structure of information flow

Name \ Document Status Report Data Schedule Technical documentation Test Plan
Name 1 W        
Name 2   M      

In this matrix we list all milestone documents of the project and how we’re going to communicate them to the team. W – means written communication, M – means meeting communication.

Generally for small and middle projects these two matrixes are enough. But for complex, large and formal projects I’d suggest to add some additional information to communication plan:

  • Provide a description of the information to be distributed, including format, content, level of detail, and conventions/definitions to be used.
  • Develop schedules showing when each type of communication will be produced.
  • Describe methods for accessing information between scheduled communications.
  • Determine when and how project communication plan should be updated. For not large projects it’s updated on monthly basis as a part of Project Management plan.
Posted in Project Management, Software Development, Technology | Tagged , , , | Leave a comment

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.

Posted in Uncategorized | Leave a comment

Project Management: Planning Phase (Brief Description).

So, we’ve come to the most important phase for Project Manager – Planning Phase. Why is it so important? The main reason is that on this phase we lay the baseline for the whole project. And with poor foundation any “building” would crash. This building – is our project, and its success depends on how we pass through Planning Phase.

The purpose of Planning Phase is to sign off key project document – Project Management Plan. I will for sure describe it in details in my future posts.

Below I will list documents/activities that must be done during this phase, and all of them are on final stage combined into Project Management plan. So, let’s start:

  • Application Design (Functional and Technical if required) – detailed description of new application and identified solution for customer and for IT. The document must be published and approved before any development has started.
  • Project Schedule – major milestones, tasks with time frames, resources accountable for tasks, critical path, deliverables and due dates. I prefer to have main plan in MS Project for everyday work and high-level plan in Excel for monthly updates to customers.
  • Costs – people time, hardware and software required for the project.
  • Risk Assessments – I’ve described this part in one of my previous posts Project Risk Management In TFS.
  • Communication plan.
  • Project Management plan.

After all activities are performed we’re moving to Execution & Control phase, but can return to the Planning phase again. This happens when project face ensure impact of any change in scope, schedule, architecture, capacity, value being delivered, etc. But in spite of this change project can still produce desired business result and value. In this case it is required to obtain agreement that a proposed change is needed and will still deliver required business value. The special Change Document is prepared in this case, to fix changes in the project.

Also, it is important to say, that from Planning Phase project manager usually starts regular Project Progress Reporting. Progress reporting should be at least monthly, but during active periods of the project (when we deal with business, start testing, prepare for go-life) I do it weekly. During one of my projects I sent reports even on daily basis – this was during final test iteration and it was important for business to monitor the amount of open issues and dynamics of issues closing.

From the next post I will step-by-step describe in details all documents mentioned above with examples from my project management experience.

Posted in Project Management, Software Development, Technology | Tagged , | 1 Comment

Project Management: Initiation phase (part 2)

In this post I will finish the story started a week ago about Project Initiation phase. We have determined high level objectives and scope of the project, put down boundaries and constraints and check whether our activity is a project or just a work request.

Now we have to prepare for detailed planning phase.

Team Roles for Planning

First of all you have to perform some planning activities for Detailed Planning phase of the project. And two next sections are about it.

Initial step is to determine the responsibilities of team members for planning phase. The points can be the following:

  • Project Lead from business (name) – organize work of working team on business side. Main contact for IT side.
  • IT project manager (name) – project planning, preparation and approve of all needed project documentation, project weekly track, organize regularly project meetings.
  • IT analytics (names) – develop and provide sign off functional and technical designs for the project.
  • Project working team on business side – consultations, approvals of some project documents.

Detailed Resource Utilization for Planning

This is the continuation of the previous section. But here I put down some timeframes and % utilization for project team members.

  • IT project manager (name) – Dec 2012 – Feb 2013, 20% utilization.
  • IT analytic 1 (name) – Dec 2012 – Feb 2013, 50% utilization.
  • IT analytic 2 (name) – Dec 2012 – Feb 2013, 25% utilization.

Signoffs Required before Detailed Planning Tollgate

In this section I determine what documents and by whom must be signoff before detailed planning phase tollgate. E.g.:

  • Project plan signoff: IT Director, Project Lead from business.
  • Functional designs signoff: Project Lead from business, Names from working team on business side.
  • Technical designs signoff: IT project manager.

Detailed Planning Phase Tollgate Participants

Here I set some dates and attendees for Detailed Planning Phase tollgate. It can look like:

  • Approximate date of meeting
  • Mandatory attendees.
  • Optional attendees.
  • Who signs off on the gate

Next Steps

Just very high-level plan of what activities we are planning to do during the project planning phase:

  • Develop functional designs for SYSTEM1 and SYSTEM2.
  • Develop technical designs for SYSTEM1 and SYSTEM2.
  • Risk Management.
  • Develop Project Management Plan.
  • Determine project team for Execution and Control phase.

This is all about Project Initiation Phase. Of course two posts were high level, but I try to make them more specific filling it with real-life examples. The next series of posts will be about Project Planning phase.

Posted in Project Management, Technology | Tagged , , | 1 Comment

Project Management: Initiation phase (part 1)

In the Project Management Request I’ve concentrated on the request pre-phase of the project and on its main document A3. If A3 has been approved by project sponsor it’s time to start project initiation phase.

Initiation phase precedes Project Detailed phase and prepare Project manager and project team for real work. In this post I will try to list all activities that better to perform and document during this phase. The output of this phase is Project Kick Off Meeting where described below information usually put into slides and presented to the team.

High Level Objectives

In this section I summarize in several points what the project is about and what results are needed to be achieved. Example from one of my projects:

  • Develop system for metallurgical waste management in Cast House workshop.
  • Create in the ERP system charge reception block.
  • Automate charge reception and outgo with barcode scanners and production scales.


This section I use to detail project team and what regions and systems project would affect. E.g.:

  • Organization structure
    • Project Sponsor
    • Project Lead from business
    • IT project manager
    • Project working team on business side
  • Technical structure:
    • The project would affect CH and FRP business units only on <PLANT NAME>.
    • The new functionality would be developed in <SYSTEM1> and <SYSTEM2>.
    • Some functionality from <SYSTEM3> will be transfers to other systems and data will be sent to <SYSTEM3> through internal interfaces.

Boundaries / Constraints

This section is rather important and must be worked out in details as soon as possible. Based on this section I set most of deadlines in Project Plan, also it’s a foundation for risk management. And if you miss anything here, with a high degree of probability the project would be unsuccessful. Also project team, project sponsor and everybody who deals with project must have the same understanding of boundaries and constraints of the project, so this section must discussed and approved if needed.

What points can be listed here:

  • The first phase of the project must be implemented into production environment till 31 July 2013 and the whole project must be closed till the end of 2013.
  • All new functionality of the project must be created in the existing systems (SYSTEM1 and SYSTEM2).
  • The project will be performed by company internal resources, no independent contractors are allowed.
  • The agreed scope of the project cannot be reduced.

Project Sizing

For this section I fill special survey to check whether this activity is a project or just a work request. For projects it’s preferable that you follow all steps of project methodology. While for work requests you can miss some steps as the activity is not so complex to perform full management.

The survey contains simple calculations and if you reach required amount of points – the activity is set to be a project. The sections of the survey are:





Project Cost; resource costs including consulting. 

<= $10K

> $10K


Project Duration

< 7 months

7 months or more


Project team

<= 10



Project manager dedication (per cent time)

<= 50%

> 50%


Well-documented, operational or maintenance processes used

Only existing, well-documented processes are to be used

Several new process are needed to be developed or modified


Team experience (in technologies / subject area needed for the project)

Trained and Experienced

Lacking some training / experience


Clarity of scope

Clearly defined

Undefined, vague scope


End User Buy-in (buy in of those who will use the result of the project)

End user acceptance a given

End user acceptance needs to be sold


Organizational Impact

Impact 1-2 business units

Impacts more that 2 business units.


Deadline and cost

Schedule and costs is flexible (+/- 1 month, +/- 20% on cost)

Deadline is fixed and cannot be changed, schedule has no room for flexibility



Proven, existing technology with in-house expertise

Unproven, new technology that we don’t have or proven technology but not in house or not proven but in house expertise


Change to current work environment, tools and/or process

Minimal change

New technology and/or new process


Number of systems to be newly integrated (may apply to applications mostly)


> 2


Number of external project dependencies

No major dependencies or inter-related projects; or only low risk dependencies to other project

Major high-risk dependencies or inter-related projects
Some dependencies or inter-related projects that are not considered low risk


Level of complexity (number of technologies, existing applications ala GAR, integrations, etc.)


Medium – High level of complexity


Number of Suppliers


> 2


Confidence in Supplier

standard, agreed Alcoa / supplier process that is reliable
there are no suppliers involved in the work

new process with Supplier, or no agreement yet made


This is all for today, it the next post I will finish the high-level description of Project Initiation phase.

Posted in Project Management, Software Development, Technology | Tagged , | Leave a comment

Project Management: Request

From this post I would like to switch from TFS reporting to Project Management. The main reason is, that I have described all reports my team is using in everyday work. But of course, if we get some new ones – I will post about them for sure.

So, what are the phases of a project? Let’s see them on a chart:


I will go through all phases in my future posts but today I will speak only about Request phase. This is a step before project stats. Its main and usually only document is A3. A3 is a story written on a single sheet.


Let’s briefly explain each section of the document:

  • Business Case:
    • Background – explains the context of the problem or improvement
    • Business Need – derived from or linked to the Business Plan and / or higher level A3.
    • Problem – specific opportunity or problem to be overcome including performance measures.
    • Current Condition:
      • Actual current state (as opposed to perceived state).
      • Identification of key issues of waste and opportunities for improvement (linked to business case).
    • Target Condition:
      • Description of the target condition.
      • Reasons why achieving target condition will address the improvement opportunity or solve the business case problem – explanation of any assumptions.
    • Action Plan:
      • List а what must be done and how (with due dates and responsible persons).

The A3 document must be necessarily approved by Project Sponsor, only then we can initialize project start. Also project team must always return to this document checking whether we’re going in right direction.

To sum up, I’m posting the example of an A3 from one of my projects:


Posted in Project Management, Software Development, Technology | Tagged , , | 1 Comment