Welcome to my webpage!

A Project Management Method - Graphically

2011-03-11T09:38:00.088+01:00

The real life business process entity is shown as an integral part of this workflow method because it requires a certain numbers of cycles to analyse, capture and structure all processes needed for the next phases. Depending on the complexity of the process, each phase might need to provide feedback for verification and/or request consensus and/or new information in order to proceed with the next phase of the workflow.

Waterfall Model
Path 1-3-5 describes a classical waterfall model ... maybe the first approach in managing a software development life cycle (SDLC). The various phases A-B-C-D are carried out sequentially but its progress is shown as flowing downwards as a water fall.

The waterfall approach gives the idea that the next phase will start when the water reaches the bottom of the fall, but it's also a way to quantify work (results) as a function of time (see diagram below).

For optimization purposes, activities within phases should be analyzed using the Project Network Diagram technique and, hence, phases could overlap.

Iterative Approach

An iterative approach is a method for delivering application functionalities in an incremental way, i.e., a single iteration can results in one or more deliverables and each deliverable represents a percentage of work to be performed. The degree of percentage of work should be such as to yield some tangible results. The result of an iteration is then used as input to the next iteration. The next iteration could take place in the same phase or the next phase, depending on its results and on the predesignated methodology policy. This process is repeated recursively until completion of an application (or project) is achieved.

The following example graph is the RUP (Rational Unified Process) from IBM and it illustrates the iterative approach.
Iteration I1, E1, C1, C2, C3, C4, T1, and T2 are similar to sub-phases and can be tailored to meet the needs of an organization.

Visualizing the state of projects using geometric figures

2011-02-27T16:06:00.024+01:00

It’s possible to visualize the state of projects using data in the form of geometric figures. This data is obtained from project performance and predictive analytics, and after calculations are performed it is put in terms of financial indicators.

The data signifies the amount, for example, of time, work and budget being completed with respect to their respective estimations. The data is represented in percentage for simple illustration purposes, but it could also be represented in normalized form for linearity relationships.

The calculations are obtained by linking real-time data activity and calculated ones such as estimates to completion for work, budget, and time, using both variance analysis and earned value methods.

The following table represents a specific instance of a portfolio management context. The portfolio consist of three projects actively being realized within their respective framework. The table below is derived from calculations based on real-time data and estimated ones.

	Scope	Time	Budget
Project A	10%	30%	50%
Project B	70%	60%	100%
Project C	50%	70%	50%

Table 1

Using Excel spreadsheet it’s possible to represent this data graphically - in this case, it could be a triangle. This is because there are three variables for both the number of projects and the number of constraints, so it’s also symmetrical from both points of view.

Graph 1

The geometric figure could change if, for example, instead of three, there are five projects being monitored with the same number of constraints (see Graph 2 below).

	Scope	Time	Budget
Project A	10%	30%	50%
Project B	70%	60%	100%
Project C	50%	70%	50%
Project D	45%	60%	50%
Project E	50%	70%	90%

Table 2

In this case, if the number of projects are used as reference to check against the values of the constraints, then the figure becomes a five-sided polygon (a pentagon).

Graph 2

Otherwise, if the number of constraints are used as reference to check against the projects, then it will be a triangle. So, in this case, there is no symmetry.

Graph 3

Only the graphical information part should be interpreted and used to determine the state of projects (similar to a dashboard approach). The added value here is that visual interpretation is easy and efficient and, moreover, supportive in a quick decision making process.

From Table 1, the algorithm for this instance could be:

Project A: at 30% of its time, consumed 50% of its budget and produced 30% of the work.

Project B: at 60% of its time, consumed all its budget and produced 70% of the work.

Project C: at 70% of its time, it used up 50% of its budget and produced 50% of the work.

Although the constraints variables are correlated, linearity is based on how the work load is distributed throughout the project, for each project.

The above example is relative to a specific instance ... a different instance will have different data. The data used in this example is only for illustration purposes.

This model is dynamic throughout the lifecycle of each project because the data is continuously processed (based on real-time activity and calculated ones).

The best way to visualize the graph is through a web/mobile application from anywhere and anytime.

(See also Forecasting Project Costs using Variance Analysis and Multiple Projects Performance Analysis using the Earned Value Method).

In case there are many projects (or many variables) to track and process, it would make sense to use a different graph that is most appropriate and easier to read.

An approach to a Cost Effective Software Solution

2011-02-02T13:18:00.013+01:00

A possible cost effective software solution is to use a technique that combines extreme programming concept and rational unified process methods. This gives the opportunity to emphasize business results already at an early beginning, before taking an incremental step in the process.

A very first step can be defined by showing something concrete to building the product with the necessary testing and revision aimed at yielding quality results and keeping track/status of project. This can be done by using iterations within each phase of the project (from pre-inception to transition). Each iteration expresses a percentage of work to be accomplished and an outcome (deliverables).

Most important, this gives the opportunity to start in a simple and agile way, building something real that works, and then try to fit it into a structure designed for further code building, rather than doing everything at once like designing an exhaustive structure at the very beginning after a thorough and time-consuming analysis (a mistake here will cost heavily).

In my opinion, this is a cost effective solution because the potential end-user/client will have visibility on the results of each step and is able to measure its satisfaction.

See Extreme Programming and RUP/PMBOK comparison.

Follow-Up: Estimating using PERT based on Beta Distribution Model

2010-11-08T18:03:00.062+01:00

This is a follow-up to my previous post about “Using PERT for estimating tasks”. The idea is not to illustrate any mathematical proofs for deriving the PERT Distribution but just to give a hint on its background.

The PERT distribution is a probabilistic model, based on Beta Distribution, and it derives its estimates based on the probability of occurrence (i.e., chance or possibility - if an event is likely to happen, we say it is probable. On the other hand, if it is not likely to happen, we say it is improbable. Directly or indirectly, probability of occurrence plays a role in the all activities. Probability of occurrence of any event will be a number between 0 and 1. Events that are unlikely will have a probability near 0, and events that are likely to happen have probabilities near 1).

The Beta Model is a flexible yet continuous distribution, defined on the interval (0, 1), that places value on the event itself and the interval between events. Because it accounts for a degree of randomness, it is highly useful in determining likely event durations (time estimates for tasks). In other words, PERT can derive a task duration with a high probability of accuracy based on three values provided by experts estimates (pessimistic, optimistic and most likely). But, it’s still an estimate because it is only as good as the estimates used in the computation.

Probability Density Function Graphical Profiles

The Beta Distribution is parameterized by two positive shape parameters, denoted by alpha and beta. It can take on different shapes depending on the values of the two parameters. The domain of the beta distribution can be viewed as a probability to describe the distribution of an unknown probability value. The range depends on the chosen shape parameters.

Typically, the general form of a distribution model is given in terms of location and scale parameters. The Beta function is different in that the general distribution model is defined in terms of the lower and upper bounds. However, the location and scale parameters can be defined in terms of the lower and upper limits as follows:

location = a

scale = b – a

Location and scale parameters

These parameters, location and scale, are used in modeling applications.

The effect of the location parameter is to translate the graph, relative to the standard normal distribution, 10 units to the right on the horizontal axis. A location parameter of -10 would have shifted the graph 10 units to the left on the horizontal axis. That is, a location parameter simply shifts the graph left or right on the horizontal axis.

The effect of a scale parameter greater than one is to stretch the Probability Density Function. The greater the magnitude, the greater the stretching. The effect of a scale parameter less than one is to compress the function.

The compressing approaches a spike as the scale parameter goes to zero. A scale parameter of 1 leaves the function unchanged (if the scale parameter is 1 to begin with) and non-positive scale parameters are not allowed.

The standard form of any distribution is the form that has location parameter zero and scale parameter one.

Ex.1: the following graph has a location of 0 and scale of 1.

Ex.2: the following graph has a location of 10 and scale of 1.

Ex.3: the next plot has a scale parameter of 3 (and a location parameter of zero). The effect of the scale parameter is to stretch out the graph. The maximum y value is approximately 0.13 as opposed 0.4 in the previous graphs. The y value, i.e., the vertical axis value, approaches zero at about (+/-) 9 as opposed to (+/-) 3 with the first graph.

Ex.4: In contrast, the next graph has a scale parameter of 1/3 (=0.333). The effect of this scale parameter is to squeeze the function. That is, the maximum y value is approximately 1.2 as opposed to 0.4 and the y value is near zero at (+/-) 1 as opposed to (+/-) 3.

Ex.5: The following graph shows the effect of both a location and a scale parameter. The plot has been shifted right 10 units and stretched by a factor of 3.

The Beta distribution in its standard form ranges from zero to one and takes a wide range of shapes (see the Probability Density Function Graphical Profiles graph on top). Moreover, it can an also be rescaled and shifted to create distributions with a wide range of shapes and over any finite range for various applications. For example, it’s used to model expert opinion in the form of the PERT distribution.

The PERT distribution comes out of the need to describe the uncertainty in tasks during the development of a complex project having thousands of tasks. Estimates were needed to be made intuitively, quick and consistent in approach.

The Beta distribution can be rescaled to model a variable that runs from a to b by using the following formula:

x = a + B(a ,b) * (b - a)

This is the four-parameter version of the Beta distribution. A version of this four-parameter Beta distribution is called a PERT distribution and makes the assumption that the mean = (minimum + 4*most likely + maximum) / 6. The default value of 4 scales the height of the distribution. This extra equation allows the four parameters to be determined from three input values: the minimum, most likely and maximum, which makes it ideal for modeling expert opinion of a variable's uncertainty.

Mean= (Min+Max+4*Mode)/(4+2)

Using the three point estimation, estimates of the mean, standard deviation and variance can be obtained:

Expected Time (ET) = ( Optimistic + 4 x Most likely + Pessimistic ) / 6

Expected time (ET) = ( Min + 4 x Most likely + Max) / 6

Standard Deviation (SD) = (Max-Min)/6

Variance (V) = =SD**2 (Standard Deviation squared)

Table Example

List of all tasks lying on the critical path of a project
Tasks	Min	MLT	Max	ET	SD	V
Task A
Task B
Task C

(All time durations are estimates).

Legend

-Min = Optimistic time is generally the shortest time in which the activity can be

completed.

-Most Likely Time (MLT) is the completion time having the highest probability.

-Max = Pessimistic time is the longest time that an activity might require.

-SD (Standard Deviation) is the average deviation form the estimated time (as a general rule, the higher the SD is the greater amount of uncertainty exists).

-V (Variance) reflects the spread of a value over a normal distribution (the SD and V will be useful in determining the probability of the project meeting a desired completion date).

ET = Expected Time

A Metric System for Measuring the Degree of Success of Managed Service Requests

2010-10-16T10:12:00.002+02:00

Indicators are useful for measuring activity efficiency and progress toward pre-designated goals. Before implementing a KPI (Key Performance Indicator) system, an organization must have clear its mission, stakeholders and objectives. This is important because KPI are quantifiable measurements and have to be agreed beforehand in order to reflect critical success factors.

KPI can vary from organization to organization, the important thing is that they must reflect the organization's objectives and must be key to its success. Key Performance Indicators may change over time as the organization's objective change.

(For illustration purposes, a simple generic case will be taken into consideration. This case can be further analyzed for specialization purposes. In practice the following could represent a managed service request in a Call Center context.)

The objective is to control those processes that determine (from the point of view of the organization) performance efficiency and effectiveness toward a target (such as a customer).

The steps to achieve the objective:

1) Choose which process to monitor (e.g., Process A)

2) Identify indicators for the selected processes (e.g., Customer Satisfaction, Delivery Time)

3) Create profile for indicators (Metrics, Family, and Source)

PROCESS -

DESCRIPTION

Family

Indicators

Metrics

Measurement criteria

Source

PROCESS A

Quality

Customer Satisfaction

Degree of success

Satisfaction level of the request/change

SLA (Service Level Agreement)

Efficiency

Delivery Time

Time

Evaluation of the response time / delivery

Response / Specifications

Quality

Quality for this process is measured in terms of customer satisfaction:

- LREQ = represents the reception level and request comprehension (the needs of the customer)

- LRES = represents the response level to the requests

The relation LREQ / LRES defines the level of customer satisfaction in the following way:

- LRES / LREQ = 1, customer requests were satisfied (e.g., as agreed by SLA or pre-defined)

- LRES / LREQ > 1, customer requests were satisfied and expectation exceeded

- LRES / LREQ < 1, customer requests were not satisfied

Efficiency

Efficiency defines the response time from the time of receiving a request.

LEFF = (Response Time) / (Receiving a Request)

LEFF

Quality

Efficiency

= 1

Requests were satisfied as

established in the SLA.

Requests were satisfied as

established in the SLA.

< 1

Requests were not satisfied.

Requests were not satisfied.

> 1

Requests were satisfied and

expectation exceeded.

Requests were satisfied and

expectation exceeded.

Sizing Applications from User Perspective

2010-10-13T18:54:00.009+02:00

Applications are software programs designed to perform functions for users or for other applications. Some examples of application include ATM programs for managing cash dispensing machines, word processors, database programs, web browsers, development tools, CAD/CAM programs for design work, and communication programs.

Application programs use the services of the computer's operating system and other supporting programs to perform a designated function, and programs communicate with other programs through the application program interface.

The idea here is not to illustrate how to build an application but how to make a high level estimation of its size from a user’s perspective. After having analyzed its size it’s possible to estimate the cost required to build it.

Applications can be big and complex or small and simple. People use web applications to order products online, make reservations for hotels, apply for jobs and so on, also, use mobile applications when on the move or travelling and, furthermore, use specific applications to communicate with cash dispensing machines to take out money or for business purposes to manage stock, to meet their customer needs and other aspects of their business.

An application that needs to interface and interact with users can be characterized by a certain number of elements. These elements in a way govern the application and they are: wireframes, use cases, business rules, data tables, reports and correspondences. The size of an application can be determined by the number of these elements. For the purpose of illustrating an example, a simple hypothetical case is taken into consideration.

Application	Number of Elements
	Wireframes	Use Cases	Business Rules	Data Tables	Reports	Correspondences
	10	50	90	100	10	15
Estimated effort to develop one element of simple complexity level in man-days	3	5	3	3	2	2
Development Effort (man-days)	30	250	270	300	20	30
Estimated effort to capture one element during the analysis phase of simple complexity level in man-days	3	3	3	3	1	1
Analysis Effort (man-days)	30	150	270	300	10	15
Total Effort (man-days)	60	400	540	600	30	45

Legend of elements:
-Wireframes are user interfaces and it’s the way the user communicates with the application.
-Use Cases describe how a user interacts with the application in a procedural way.
-Business Rules govern the flow of procedures and data.
-Data Tables are the data required for the application to perform its function.
-Reports are printable information.
-Correspondences can be notes, messages, and emails.

N.B.- All of the above elements are managed by the application. The numbers in the table above do not refer to any industry standard, they are all hypothetical numbers just for calculation and illustration purposes.

Mathematical format:

By introducing hypothetical unit rates per day it’s possible to calculate the relative and total costs.

-Development unit rate per day = $300

-Analysis unit rate per day = $500

Putting data in table format:

Costs
Total Effort Development in man-days	900
Developers rate per day in $	300
Developers Cost in $		270000
Total Effort Analysis in man-days	775
Analyst rate per day in $	500
Analysts Cost in $		387500
Total Cost in $		657500

All data in this example is hypothetical. For better accuracy it’s possible to add more variables and factors to this approach.

Forecasting Project Costs using Variance Analysis

2010-10-04T16:59:00.009+02:00

One way to report on cost control and forecasting during project execution is to use the Variance Analysis method, that is, explaining the difference (or variance) between actual costs and the budgeted costs with numbers and make new estimates for completing the work. Please consult this link Earned Value Management for related literature and references.

For the purpose of making these calculations, I will use an hypothetical project example (but it could also be a task or phase).

"A company has contracted a service provider to deliver a project in 10 working days (80 hours) for the estimated cost of $10,000 and a work effort of 200 hours. The contract is Time and Material, this means that the company pays the provider for the number of hours actually required to perform the service. So, the provider has no incentive to minimize the number of hours expended on the service. The less efficient the provider is, the more money it makes!"

Summary of Time and Material Contract (representing the initial estimated baseline):

- 2 weeks duration (=10 working days)

- $10,000 cost (= budget at completion)

- 200 hours effort

Situation after 5 days:

- Service Provider completed only 40% of work

- Company received $6,500 invoice from provider (actual cost after 5 days)

- Time sheet = 100 hours (actual number of hours spent on project after 5 days)

Using variance analysis to calculate data and to do forecasting:

After 5 days	BAC *(Baseline)*	Estimated after 5 days	A (Actual)	ETC (Estimate to Complete)	EAC (Estimate at Completion)	% Completed (A / EAC)	VAC *(BAC-EAC)*
Work (%)	100%	50%	40%	60%	100%	40 %	0
Cost ($)	10,000	5,000	6500	6500 ^(b)	13000	50 %	- 3000
Duration (days)	10	5	5	7^(c)	12	41.6 %	- 2
Effort (hours)	200	100	100	120 ^(d)	220	45.45 %	- 20

a) ETC Work is 60% because only 40% was done. The percentage change between the estimated and the actual is -20 = (4-5)/5x100, this means that the actual work is behind 20%.

b) ETC Cost = $6,500. The %change = (5,000-6,500)/5,000 x 100 = -30%, the negative sign means that the expenditures exceeded the budgeted amount at 50% of the executed time. Hence, ETC Cost = $5,000+ 30% of $5,000= $ 6,500.

c) ETC Duration = estimated + % of work to recuperate = 5 days + (20% of 10 days) = 7 days estimated to complete

d) ETC Effort = estimated + work lag to recuperate = 100 + (20% of 100) = 120 hrs

VAC (Variance At Completion) = BAC - EAC

A graphical representation of the cost at T = 5 days:

Forecast :

- + 7 days to complete 60% of the work

- Cost= +$ 6500

- Duration = + 120 hours

N.B.- If the project is still not completed with the new baseline, there is a need to make new calculations for a new forecast.

Multiple Projects Performance Analysis using the Earned Value Method

2010-09-27T16:44:00.007+02:00

The assumption made here is that anyone reading this example has some background in Earned Value Management. If not please consult this link Earned Value Management for related literature and references.

For the purpose of illustrating this method, I have created a table containing three hypothetical projects with their respective baselines. Each baseline is defined in terms of duration, effort and cost for each single project.

The idea is to carry out a performance control half way down the timeline for each project and verify that all projects are in line with their respective plan. This could be a major milestone or a check point. Normally, there are many planned check points throughout the life cycle of a project, but for the purpose of this example only one point is taken into consideration.

This method uses the actual cost of the work done, at a given point, and the planned cost to calculate and compare values for cost and schedule variations. This information is also calculated in terms of cost and schedule performance indexes.

The actual cost factor is what really links the operating company to the ongoing project and could comprimise the project or the company or both if not properly monitored and controlled.

The following table summarizes the calculations needed for graphing and deducing the results relative to project performance at a given point.

Cost and Schedule Variances

Variances: positive variance is good; negative is bad.

Situation at half time:

Project A: CV is less than 0 and SV is greater than 0; the cost of the actual work exceeded the value of the work done (the project is over budget and ahead of schedule).
Project B: CV is less than 0 and SV is less than 0; the amount of work done is inferior to the budgeted amount.
Project C: CV is greated than 0 and SV is greater than 0; the cost of the actual work is inferior to the value of the work done and the amount of work produced exceeded the budgeted amount.

Atlhough Project A is ahead of schedule, it's using up too much money too fast with respect to the plan. The risk is that it will use up all the budget before completion of the project.

Cost and Schedule Performance Index

Performance index: greater than 1 is good, less than 1 is bad.

A Simple Method for Keeping Track of Project Performance using the Earned Value Method

2010-09-21T08:41:00.039+02:00

The Earned Value method is a little different from the classical approach for keeping track of project performance. It has an extra variable that represents the actual cost of the work done at a given point, and it is obtained from the organization 's accounting system. This data is compared with the earned value to show the amount of work that was planned with what was actually accomplished to determine if cost and schedule performance is as planned. So, it's possible, at any given point, to compare how much actual work has been completed against how much is expected to be completed and graph the results for quick referencing.

Example of Graph

Reading the above curve

CV is less than 0 : the cost of the actual work exceeded the value of the work done.

SV is greater than 0 : the quantity of work done is greater than the budgeted.

CPI is less than 1 : spending more than the value of the work done.

SPI is greater than 1 : more work done respect to the budgeted (ahead of schedule).

The above curve is just for illustration purposes and it was produced with Excel. It's possible to use a different curve and normalize all numbers so that the data will be uniformely distributed over the graph.

For an example analysis work on this type of application, send me a message by clicking the Contact Me button on top of right column.

A Global PMO Work Model

2010-09-14T10:28:00.034+02:00

Today’s globality can help bring many advantages to an organization and, thanks to the Internet, it’s easy to design, implement a work model for managing projects globally.

Many companies have activities all over the world and need to maintain a company wide standardisation and an overall co-ordination through the process of monitoring, controlling and reporting all activities. This is important in order to maximize results (profits), minimize risks, optimize use of resources and make improvements in communication.

The above diagram is proposing an integrated global framework model that can provide on-going feedback for alignment and adjusting changes through a structured and distributed effort system.

The framework is simply governed by a on-going "process-improvement-process" management system and serves as the point of reference for all project/engagement management activities. It contains things such as how to set up a project/engagement, project approval processes, planning and estimation techniques, management methodology (structuring and managing projects throughout its life cycle, set of formal deliverables that should be produced, common terminology, etc.), risk management process, issues management process, etc.

The process-improvement-process management system manages the whole framework in a continuous way, by elaborating feedbacks from the global team and producing output to continuously improve processes, communication and performance and, moreover, assuring alignment within the framework.

Cultural impact in an international context

Although cultural differences should not constitute a problem there might be some differences in people's approach, but this can be overcome by experience, understanding and flexibility.

A graphical representation of a typical project and product management approach and the relationship throughout their life cycle

2008-12-28T06:39:00.067+01:00

Comparing a typical project management approach to PMI process groups and to a product approach, with respect to their life cycle.

It's possible to apply all PMI process groups to each phase of the product life cycle.

The result could be represented in this graph. The approved proposal of a new product could be used to initiate a new project. At the end of the project this will yield a new product needing support in a commercial context.

Project Network Diagram Information and Data

2008-09-22T15:31:00.032+02:00

The information and data needed to document a project network diagram is obtained by calculating and analyzing dates, estimating durations, and, if needed, cross-reference data from the WBS (Work Breakdown Structure). These tasks should be (and mapped into) the lowest level of the WBS, i.e., at task level. Operationally, this diagram represents the dynamics of the project, i.e., how the tasks are placed in relation to each other, with respect to time and effort. No single taks can be placed pending whithin the project network diagram.

Build and Deploy a Project using OO technology

2008-09-12T03:29:00.019+02:00

Once the process of analyzing and gathering requirements is completed (well...at least one iteration), then it's possible to proceed to the next phase: building the application.

Modelling

-Modelling has to do with designing the technical architecture in detail. From use cases it’s possible to create object models and sequence diagrams to describe the static and dynamic nature of the application.

-Here there is a need to create deployment diagrams that describe the tiers and processing nodes required to support the application.

-During this process there is a need to create the information architecture and illustrate how it ties to the data dictionary, navigation features and content types into a cohesive site map.

-The information architecture is created with the use of user scenarios, storyboards and site maps that precisely describe the interface before the project moves to the build stage.

-The Interface Design is driven by the use cases that describe the requirements of system.

-Using the same documents as input to both the Interface and Technical Designs ensures that the system is consistent from front to back.

Build

-During the build phase, designs are translated directly into source code so the application mirrors the business environment directly.

-Object model programs are developed to model the business environment, transaction programs to update the model, web pages to present the model, databases to store the model, and connectors to integrate other systems.

-It is good practice to develop automated unit tests in parallel with the application and run them in order to ensure that new code doesn't break existing code.

-Simple structural rules are coded directly into business object programs.

-Complex logic that affects several business objects is coded into transaction programs.

-Transaction programs are layered on top of the business object programs.

-The site map and interactive architecture are used to render web pages that create the look and feel of the system.

-Input validation and other simple business rules are coded directly into the web pages to improve the user's experience. These pages are integrated with server-side business logic to deliver advanced business applications across the Internet.

-All non-trivial web applications must work with other business systems.

-These systems include relational databases, transaction monitors, mainframe applications and third-party systems.

Test

-In addition to the automated unit tests created during the build phase, it’s possible to test the complete business functions of the application at the end of each iteration.

-The application is deployed to the test environment so capacity and resiliency testing can be performed.

-Installing the application in the test environment at the end of each iteration forces operations staff to take ownership of the application long before the application is released to end users.

-Operations scripts and processes can be developed in parallel with the application, which reduces the overall duration of the project.

-During the test phase, defect reports are collected and analyzed.

-Defects in early iterations can be avoided in later iterations.

Deploy

-During the deployment phase the application makes the transition to its user's community, which includes manufacturing, delivering, training, supporting, and tuning the application until the users are satisfied.

-Once the application is deployed, warranties and service level agreements come into play to ensure the ongoing success of the application.

-Training materials are developed to help users make the transition to the new application.

-Finally operations scripts are developed to manage the application.

Project Opportunities from Cause-Effect Case Analysis

2008-08-30T20:18:00.028+02:00

An opportunity might arise as a result of analyzing the cause-effect of a specific case. For example, a company, for the last two years, is experiencing an exponential increase in the volume of their transactions, due to new business.

As a consequence, it’s having difficulties managing and, most of all, executing all business transactions, especially those ones that are date and time sensitive. This is because its present IT system is being gradually overloaded and is having an impact on performance.

For this case, a very high level presentation of the problem could be:

CASE: A general description of the case.

CAUSE: A decription of how business increase is overloading the present IT system.

EFFECT: A description of how overloading the present system is causing a decrease in performance and causing gradual saturation.

IMPLICATION: A description of the consequences. For example, the company will not be able to mange new or more incoming business due to the effect.

Analyzing the solution:

Analyzing the solution requires serious thinking on the effect and to start discussing what is needed to resolve it ... providing a few options.

Possible outcome after analyzing the problem might be:
(in order to keep up with increasing demands)

Upgrade the present IT system to handle the new volume capacity
Migrate to a new IT system with different technology

The next step is to start analyzing what is required to satisfy the needs. The needs are then translated into requirements and they will serve as the basis for the project plan. This will reduce the effort of determining how best to meet requirements. They may be written as a statement of work (SOW).

Project Network Diagram Analysis

2008-08-15T19:08:00.035+02:00

Once the Project Network Diagram has been created, it can be tranformed into a working activity diagram by adding useful information to each activity box.

Each activity box should contain:

- A unique identification number for each activity (no two activities can have the same number on the same project).

- A clear activity description which would aid in identifying the predecessors and successors to the activity.

- Duration estimate (illustrated in the diagram).

On large projects it is a good idea to include the activity WBS and or OBS codes in order to clearly group and identify activity relationships.

If there is enough room in the boxes, then other type of information can be included, but only if it helps in the network building process, such as project cost. However, the more information you include (other than the minimum items listed above), the more variables you need to deal with and the more difficult it becomes to build one.

Once the project network is built , it follows logically to calculate the start and finish dates of each activity based on the following:

- The start date of the project (the start of the first activity).

- The duration of each activity.

- The logical sequencing of the activities as drawn in the network diagram.

The groups of activities that make up the longest path and therefore produce the projects' end date are known in the project management industry as the “Critical Path Activities”. Activities that are not on the critical path will have slack or float.

Project Scheduling using PDM - Project Network Diagram

2008-08-05T22:27:00.015+02:00

A Project Network Diagram is a logical or technical representation of all the activities in a project showing their dependency relationships.

Those logical relationships are also known as:

-Activity Dependencies

-Activity Constraints

-Activity Connectors

In building the project activity network we are in a sense building a paper model of the method or process by which we intend to execute and deliver the project. There are different techniques for creating project activity networks. One method used is known as the precedence diagramming method or (PDM). This method uses a box (square, rectangle or any other shape you prefer) represents each activity with arrows (not lines) connecting these activities and representing the precedence (predecessor and successor) relationships.

Project Scheduling by Gantt Charts

2008-08-04T03:07:00.010+02:00

Bar or Gantt charts (Henry Gantt - Bar chart inventor) are a visual technique for listing the project activities within a specified time frame. Each activity is identified with a start and duration. Bar charts will also depict when activities should start and finish. Gantt charts are used to show planning, progress to date and slippage against the baseline type information.This type of scheduling tool is used where more detail is required in the project plan.

Using the WBS for a project, Gantt charts can be summary or detail in nature.

Project Scheduling by Milestones

2008-07-02T22:58:00.015+02:00

Milestones are events representing the start or finish of major phases of work or deliverables. They are more commonly used to estimate or flag the finish rather than the start of activities.

Milestones are used for:

-Planning phases of work (Top Down)

-Controlling project progress

-Communicating project deliverables and status

For example:

-Milestone A To Be Completed Feb 5

-Milestone B To Be Completed Apr 20

-Milestone C To Be Started Mar 1

-Milestone D To Be Completed May 15

-Milestone E To Be Started on July 30

Validating The Project Estimate

2008-06-27T00:06:00.029+02:00

A project manager should be familiar with the procedural and/or legal requirements associated with the use of project contingency. In many situations the owner thinks of the contingency as the amount of funding available to add more scope if need be. The project manager typically views the contingency, as funds to be tapped, if the project is delayed for whatever reason. Contingency should cover the uncertainty for risks that are difficult to estimate portions of the project. Therefore, it's important that the documentation surrounding the use of the contingency amounts is well documented. It will come in handy when meeting with the client on project changes.

When validating project estimates, check:

- Level of Detail In The Requirement Document

- The Method Of Estimating Utilized

- The Experience Of The Estimator

In any case, it is safe always to estimate a contingency value, that is the amount of “set a side” in dollars or hours, which is over and above the initial project estimate. This is necessary to cover risk related items and to provide coverage for items that were difficult to identify in detail during the time the estimate was prepared. Risk and contingency are interrelated, the higher the risk the greater need for contingencies.

Contingency estimating is a tricky process, and it's best to follow a process:

-List all risk items

-Verify mitigation approach or steps to the solution

-Consider the degree of uncertainty (subjective) associated with each

-Add a percentage amount 10, 20 % etc. The percentage amount is based on:

-History

-Contract Provision

-PERT

Project Cost: building the project resource sheet

2008-06-14T23:43:00.030+02:00

Project cost is defined as the approximate (estimated) cost of all resources (people, materials and equipment) consumed by the performing organization necessary to achieve the project deliverables.

Using this information it is possible to build a project resource sheet, such as illustrated in the table above.

-Resource names can be individuals or generic.

-Resources should be coded uniquely.

-Resources must be grouped for hours.

-Rates must be assigned to generate cost information.

-Max. average Availability per day to work on this project only.

An example of estimating the cost of a task could be:

-to develop a software module in 10 days

-2 resources available (given on a unit effort per day) :

-a programmer @ 20% per day, at a rate of $50/hour.

-a contractor @ 10 hours per day, at a rate $70/hour.

Calculating Total Effort = 116 hours

-programmer: 20% of 10 days = 2 days = 16 hours

-contractor: 10 hours/day per 10 days is 100 hours

Calculating Total Cost = $7,800.00

-programmer: $50/hour x 16 hours= $ 800.00

-contractor: $70/hour x 100 hours= $7,000.00

Project Estmating Techniques

2008-06-05T14:18:00.016+02:00

There are different ways for estimating project tasks and, consequently, the overall project. Here's a few of them:

Use of Historical Data - if projects are categorized in a knowledge database system, together with learned lessons, then they can easily be retrieved and consulted for estimating purposes. Of course, they have to be similar projects.

Use of Experienced Resources - estimating is a team effort, and the contribution from experienced resources in making estimation is very valuable.

Use of Estimating Databases - if available, make use of industry databases published by organizations.

Range of Estimates using PERT Weighted Average equation used for statistical based risk analysis.

E= (O+4M+P)/6 = Expected Value; O= Optimistic Value; M= Most Likely Value; P= Pessimistic Value

Other?

In any case, points to remember when estimating are:

-Use experienced people

-Emphasize team estimating

-Breakdown to 1-2 weeks for control

-Itemize the doneness criteria for tasks

-Do not estimate for others (detail only)

-Check resource hours vs. time elapsed

-Try to be realistic not optimistic and not pessimistic

WBS & OBS Matrix Table

2008-02-10T16:05:00.003+01:00

Organizational structures represent the enterprise grouping of resources to perform work. This work can be project or non-project related.

Once the WBS and OBS are developed the two structures can be intersected to generate a responsibility matrix table. Each Work Package or activity will have a WBS code and an OBS code indicating who is responsible for the delivery of what package.

For most projects it is recommended that the first level of the WBS be time phased oriented typified by your organization’s system development methodology (Definition, Analysis, Design, Development, Testing, Installation, Training etc).

Per type and size of the project, each phase can be decomposed in to more detail into smaller and more manageable components easy enough to assign clear responsibility for completing the task.

Work Breakdown Structure (WBS)

2008-02-03T14:27:00.002+01:00

A Work Breakdown Structure (WBS) is a methodical way of decomposing the project work into meaningful and logical smaller pieces for the purpose of planning and control. When completed the WBS should include all activities associated with the project scope.

It becomes the data dictionary for communicating on the project. Work Breakdown Structures have a child / parent relationship which means that it's possible to roll up and summarize any information from the lower levels and upwards. This is true for activity cost, resource effort and schedule information.

It can also be used to assign responsibility for groups of activities to different functional managers for planning and or accountability purposes.

It should also be used as the format for capturing and outlining changes to the project. One way of representing the WBS is to outline the format similar to a “Table of Contents” in a book.

An example could be:

Another way is to outline the format like a tree structure similar to a Company’s Organizational Chart.

In any case, the lowest level is known as a work package, which would be made up of a number of activities or tasks with clear resource assignments and functional responsibility assigned.

There is no limits to the level of detail one can go down to, nor there's a need to have the same number of levels for each branch.

However there should be guidelines to assure the desired level:

• assign responsibility of definition and completion for accountability purposes.

• estimate the required resources and their required hours/days of performance.

• estimate the duration (elapsed time) between start and finish of the element.

• identify logical predecessor and successors to the element.

• short enough so that it's possible to define its doneness criteria for control and progress capturing purposes.

Note: The more detail one creates the more time and effort is required to maintain the WBS. One has to decide on the trade off between more control (i.e. detail) and overhead (i.e. amount of data to update).

There are many approaches to breaking down the work into smaller packages. Since the data can be rolled up and summarized into different levels, the approach one initially takes will decide on what kind of information it will be able to report on. Based on one's reporting requirements and type of project, it's possible to mix and match formats at different levels.

Risk Management

2008-01-21T20:02:00.001+01:00

A risk can be defined as an undesirable development, about which there can only be a degree of certainty that it will happen, but if it does happen there will be a significant impact on the project.

Lack of certainty implies that there is a probability, but not certainty, associated with the risk. The impact of the risk implies that there will be an effect on the project, in terms of time, cost or quality.

The exposure of the project to the risk can be calculated from this:

Exposure = (Risk Probability) x (Risk Impact)

On its own, the figure for exposure indicates the scale of actions required to keep the risk under control. For example, if the risk impact has been calculated to $10,000 and the risk probability is 0.5%, then the exposure is $500. This means that the scale of action to be taken to track the risk should have a value of $500 approximately. This indication is essential when estimating task cost and duration. By adding criteria to the exposure, a metric system has been achieved. Undesirable events should be identified and managed throughout all phases of the project. Once a risk has been identified and planned for, it as to be managed as a task. The below diagram illustrates the MSF Risk Management Process.

More important, prior to making the project plan, there's a need to analyse the context of the project and identify the categories of risk sources and their consequences. The following example are based on MSF Risk Sources.

A simple way to software sizing measures

2007-08-30T11:38:00.001+02:00

There are different ways of measuring the size of software applications, such as measuring lines of code or functions points. With lines of code the size is measured after the application has been built. This approach is dependent on the technology used to build the application, its design and the programming languages used for code. Applications coded using different programming languages cannot be easily compared and this might compromise efficient code.

With function Points the size is a measure of delivered functionalities that is relatively independent of the technology used to develop the application, and it's measured from the user's perspective. Therefore, sizing the application is done by counting external data (inputs, outputs, interfaces, files and inquiries); this might not be so intuitive and difficult to communicate.

A simple way to size an application is to use a more intuitive approach. This is analogous to function points approach, but it's made more simple by using parameters in an approximative way. For example, during the analysis phase, it's possible to capture information related to the number of use cases, user interfaces, reports, rules/algorithms, and data tables needed for a particular application. Each component (i.e., each UI, each UC, each Report, etc...) is multiplied by the estimated effort needed to build it. This operation is done for all components, and a total effort is calculated and easily converted into costs.

Project Cost

2007-08-26T13:44:00.002+02:00

Project cost is defined as the approximate (estimated) cost of all resources (people, materials and equipment) consumed by the performing organization necessary to achieve the project deliverables.

If a WBS (Work Breakdown Structure) scenario is used to contain information related to resources, estimated effort and activity duration, then, if costs are added to the WBS, it could represent the project cost center. In organizations the administration-finance department will supply an average cost per hour or per day of different types of resources. These rates would represent their average salary rate plus company burden, overhead and profit margins.

In for some reason, it's not possible to post rates against resources (because of company policy), then it's possible to calculate the cost of the project on a person day basis.

For example: 1 person day = 8 effort-hours = 1 day (8 hours) x 100% (1 person)

In general: Resource Effort (or Work) = Time Elapsed (or Duration) x Percentage of Utilization (or Units)

This cost estimating process will help to verify which portions of the project can be kept in-house versus work that can be farmed out for cost saving measures.

If the WBS is loaded with the cost and the activities scheduled, it's possible to conduct financial time phased analysis (Cash Burn Rate Analysis: that is, measure the rate of negative cash flow (cash going out > cash coming in), over a given period of time). This is important particularly for large projects that require multi year financing.

Using PERT for estimating tasks

2007-08-21T16:00:00.009+02:00

A simple way for estimating tasks is to use the PERT (Program Evaluation review technique) weighted average method. This method uses a weighted average duration estimate to calculate task duration, it gives the opportunity to take into account information based on different types of estimates values (such as poorly defined areas, probabilistics, and ranges for the schedule). This method is based on the Beta distribution model because it can model events which are constrained to take place within an interval defined by a minimum and maximum value. (For this reason, the Beta distribution is used extensively in PERT, CPM and other project planning/control systems to describe the time to completion of a task).

The term weighted average means that the equation uses weighted factors to calculate the expected task duration.

The equation and process modelling a task for PERT is the following:

E=(O+4M+P)/6 (equation)

E= Expected Value

O= Optimistic Value (this is equivalent to a minimum value)

M= Most Likely Value

P= Pessimistic Value (this is equivalent to a maximum value)

(i) Fist, acquire estimates for the pessimistic value, most likely value and optimistic value time to completion. For example, let's suppose that: P=20 programmer days M=12.5 programmer days O=10 programmer days

(ii) Then, using the "PERT Weighted Average" equation: E=[(10+4(12.5)+20]/6 = 13.333 programmer days = expected task duration = mean value

The Needs/Requirements Life Cycle

2007-08-04T08:26:00.004+02:00

Specifying what the project should accomplish is not an easy task and is not to be taken for granted that everything is clear. It's easy to misunderstand requirements and transform the whole project into a tragedy.

What causes the need for requirements?

Well, something has to happen to trigger it...maybe a cause-effect situation, or a change request for something or an action that causes some changes.

For example, let's suppose tha a legal company expands its offices throughout the nation, and as a result they need to enhance their information system and improve communication perfomance. From this situation a need emerges and, in order to meet these needs (system and human), it must be recognized through conscientious effort. Asking questions (from both points of views: ours and the customer) on the cause and, consequently, on the need will help, and it might be best to establish procedures for identifying these needs in a systematic way. Also, it's important to give special attention to focusing on anticipating needs, and not just on the existing needs. Anticipating needs can be accomplished with a two-hour brainstorming session. This session is useful to develop ideas of what future needs might be. This forecasting is called scenario building.

Once the need is recognized, it must be clearly articulated. This entails an in-depth scrutiny of the recognized need. Look also underneath the surface, so as not to lose sight on reality. The face value is fine, but don't neglect the rest. Articularing the need has a practical side too: it serves as the basis for the developement of functional requirements, by stipulating in concrete terms what has to be done to achieve it.

To minimize the risk of doing a poor job in articulating the need, it's best to:

(i) ask those who have the need to define it as clearly as possible,

(ii) ask a full set of questions about the need (information, curiosity, data,...),

(iii) carry out whatever research is necessary to better understand the need,

(iv) in view of insights gained in the first three steps, try to formulate the need the best way you can,

(v) ask the customer to respond to the formulation of the need and revise accordinly.

Carry out the above steps only by working closely with the customers, getting their reactions to the newly articulated needs, and revising the needs statement to reflect customers desire.

After the needs have been carefully defined, it's possible to use them as the basis for developing a project plan. This is done by formulating the needs as functional requirements.

Functional requirements describe the characteristics of the deliverable in ordinary non-technical language, i.e., what emerges from the project. Here it's possible to use graphic images to strengthen its contents.

They should be understandable to the customers, and customers should play a major direct role in their development.

While functional requirements are designed to assure that customers know what they are getting out of a project, technical requirements are written for the technical staff. They describe the features of the deliverable in detailed technical terms (such as physical dimensions and performance specifications). They offer project staff guidance on what they should be doing on the project. Because of their technical nature, technical requirements are often incomprehensible to the customers, who lack the training to know what they mean.

In a software project, for example, the functional requirements may stipulate that a data base system will be developed to allow access to a finacial data through remote access; the corresponding technical requirements would spell out the architecture of the data structure, the language in which the data in which the data base management system will written, the hardware on which the system will run, telecommunications protocol that should be used, and so forth....

Hence, project requirements are important for two reasons:

(i) They are a tangible embodiment of the customer's needs (needs emerge, needs recognition, needs articulaton, and then they are translate into requirements, which serve as the basis for the project plan). This will reduce the effort of determining how best to meet requirements.

(ii) Requirements are important because they define the project team's obligation to the customers.

They also describe the team's responsibilites. Projects that run under contracts, the requirements may be written as a statement of work (SOW), and compliance or non compliance with the contract is determined by resolving whether the contractor has fulfilled the SOW.

Functional Analysis

2007-07-25T16:23:00.008+02:00

Some people exchange the term functional with business in functional analysis activities. There is a difference between business and functional analysis. In my opinion, business analysis is the process of analyzing the business process(es) and producing a model of the business for the purpose of improving it or optimizing it. This is because it's much easier to work with models. On the other hand, functional analysis, in an application context, is the process of analysing the sum of functionalities that produce the logic of how things function and work gets done.

Before analyzing a business context, let's say that Information Technology as a tool to support human activities might not "support" all processes. This is becasue some processes cannot be digitalized and, hence, need to be carried out by people. For example, when ordering a product from internet, the process of bringing the product to your home is done by people. Maybe this will change in the future, like in the Star Trek series, allowing an object to be transported to its destination in a beam and then the object is rematerialized. But, until then, there's a need to properly analyze all processes that make up a business scenario and determined which ones can be digitalized, and which ones cannot, and design the whole process scheme with methods that facilitate technology implementation.

Hence, we need to start somewhere. Knowing nothing about the business context, the best way to start is to organize a series of interviews with the people that run the business and have knowledge of all activities and processes. This investigation can be conducted in different ways, for example:

(i) individual interviews,

(ii) workshop involving more people.

Any of these two case will do, just be aware on how much time is given to capture this information and on the availability of the person being interviewed. The time required for this type of analysis is proportional to the level of complexity of the process to be analyzed. What is important here is to use a serious and structured approach in order to have the opportunity to capture all steps involved in each process of the business. Each process has to have a purpose, entry criteria that triggers it, input(s), tasks (a list of actions bringing the results), output(s), work aids (there might be functionalities to support the process), and a criteria for exiting the process. This can be structured in the form of a template to facilitate the analyst.

An applications may consists of one or more fucntionalities. There's also a need to identify other important aspects of an application, that is, those characteristics that enables a user to have a set of capabilities. Let's call these characteristics features. For example, on a a cell phone, text messaging is possible thanks to the gsm technology. So, if the cell phone is represented by the application and text messaging is one of its functionalities, then gsm is a feature of this applicaction (because a user is capable of sending a text message). Hence, as part of the analysis, a list of features can be captured and described.

The next step is to analyze the way a user interacts with the application. Again, this shall be done by organizing a series of interviews and/or workshops with users/subject matter experts that are already interacting with computers and have knowledge of all functionalites from user's perspecitve and, perhaps, desire to have a new application.

The analysis work is accomplished by describing the way users interact with the application to get the job done (this includes all steps and the logic of business rules). Activity diagrams, which are similar to flow charts, can further support the application by describing the the flow and logic of the activities (use cases, business rules,...).

After having analyzed the process and captured a few use cases and other elements such as the number of reports, the number of screens (user interfaces), algorithms and data needed for a specific application (or at least have a good feeling of most elements), it's possible to make an estimation on its size and determine how much effort is needed to build the application.

Program Management

2007-07-16T16:40:00.002+02:00

To get a better understanding of program management let’s look at the difference of definition between a program and a project. PMI (Project Management Institute, an established organization for project management practices) gives the following definitions:

-a program is “a group of related projects managed in a coordinated way, usually include an element of ongoing work”,

-a project is “a temporary endeavour undertaken to create a unique product, service, or result”.

By definition a project has a temporary endeavour; this means that a project has a finite period of time (a start and end date) to carry out what is described in its scope. The scope defines the boundaries of a project (the amount of work to be done). Exceeding the boundaries could mean out of scope. A project, per se, sounds like a static entity, but within a timeframe the situation changes… it's a dynamic environment. This means that a project progresses with time and each single point of time has to be managed in order to identify its status (the situation of a project). Managing a project means applying processes, techniques, and tools, related to a methodology, throughout its life cycle (“from birth to retirement”).

The point is that project management has to do with activities that lie within the project's timeframe and framework of reference. Program management, on the other hand, wants to deal with this from a different perspective. It will look at the project from a different dimension (or external to the framework) to take decisions on the situation of one or more projects,at any particular time.

This is achieved by setting up an ongoing structured system for monitoring, controlling and reporting activities on designated instances, within the timeframe of a project.

The system has also to balance the following:

(i) optimizing the use of resources,

(ii) minimizing risks, and

(iii) maximizing results.

The parameters to be balanced are such that they will assure stability, if not improvement, on the company’s strategic objectives, through the success of project’s results. Some parameters might include risks identified, scope, resources, budget allocated, time …

Monitoring is achieved by having a schedule of meetings throughout the year, with the project team of each project. Controlling includes comparing and verifying that parameters are within a certain range of acceptability (metrics are used for measurement’s purposes), with respect to the baseline. Reporting should be done at different level of details: data-graphics for top management, data-graphics and summary for middle management, and more detailed information for lower management.

For project oriented organizations, this is an ongoing activity. Furthermore, when managing multiple projects it is important to add another variable to each project, the priority. This variable needs to be managed, especially, in critical situation, e.g., if a project that is strategic for a company and is in a critical situation, it might be possible to “borrow” resources from a project that has a lower priority.

In conclusion, as a result of this ongoing process, overall project management performance will definitely improve.

Teleworking

2007-07-10T13:56:00.004+02:00

One of the ten applications outlined in the Bangemann report (a white paper published after a meeting held in Brussels in June, 1994) is Teleworking. Martin Bangemann was one of the twenty members belonging to the High-Level Group on the Information Society. The aim of this group was to give recommendation to the European Council about Europe and the global information society. After the meeting, a report was requested by the European Council and, on the basis of this report, it would have adopted an operational program defining precise procedures for actions and the necessary means to achieve them. Teleworking is perfect for independent professionals that require a certain degree of freedom in their endeavour. This post-information era is tending, more and more, to an economy system based on individual productivity, where it's possible to measure results in terms of money. But, in a project oriented environment where the work is handled by a team (a group of people usually being in the same physical place), can teleworking be applied?

A complex project usually is broken down using a technique called Work Breakdown Structure (WBS). This technique gives the opportunity to decompose, in a methodical way, the project work into meaningful and logical smaller pieces for the purpose of planning and control. This becomes the data dictionary for communicating on the project; furthermore, it should include all activities associated with the project scope, it should have have a child/parent relationship (which means that you can roll up and summarize any information from the lower levels and upwards -- this is true for activity cost, resource effort and schedule information), and it can also be used to assign responsibility for groups of activities to different functional managers for planning and or accountability purposes. It should also be used as the format for capturing and outlining changes to the project.

The WBS makes it "easier" to manage (monitor and control) the project work, if the team is all in one place. But, with telework the work place becomes "virtual". This means that team members might be dislocated to different parts of the world, including the people that are accountable for keeping track of the project's progress and status. Assuring that results are maximized, resources optimized and risks minimized can be accomplished through an integrated global PMO evolutionary mechanism ... this will solve the problem of the "distance global manager".

Micromanagement

2007-06-13T07:12:00.003+02:00

Micromanagement has become a very popular descriptor in today’s workplace. Webster's Dictionary defines micromanage as “to manage with great or excessive control or attention to details.” Most people today hear these words and immediately think of the annoying manager who constantly looks over their shoulder, questions everything they do, won’t let them make any decisions; and runs his/her office like a military command and control center. To be fair, not all managers who are given this pejorative title deserve it. It is the role of a manager to monitor progress, control quality, evaluate performance, make decisions, give instruction, and offer advice and guidance.

For example:

(i) if deadlines are missed or customers are not satisfied, a manager needs to get more involved in the details to help solve the problem,

(ii) or if a project is not going as planned, a manager needs the details in order to adjust the plan and/or make the necessary decisions,

(iii) or if a staff member is not able to perform, a manager needs to become more involved in their work in order to coach them effectively,

(iv) or if a staff member is not willing to perform, a manager needs to monitor their performance closely in order to motivate or discipline them accordingly,

(v) or if a manager has to report on progress, he/she needs a detailed understanding of the processes and inner workings of the department,

(vi) or if a staff member is responsible for a sensitive file/job, a manager may need to know all the details in case the staff member is absent.

Sometimes these managerial responsibilities can appear intrusive or controlling to staff – particularly to those who are under-performing and require more supervision. It is only when a manager’s oversight or input is excessive or unnecessary that he/she can be reasonably termed a “micromanager.”

The Earned Value method to keep track of project performance

2007-04-24T16:05:00.001+02:00

This method is a little different from the classical approach of keeping track of project performance. It has an extra variable that represents the actual cost of the work done at a given point, and it is obtained from the organisation 's accounting system. This data is compared with the earned value to show the project's performance situation running over or under. So, it's possible, at any given point, to compare how much actual work has been completed against how much is expected to be completed. This makes it possible to measure performance and predict the outcome of project.

Structuring into forms

2007-04-08T19:08:00.003+02:00

These problems representing the characterization of a phenomenon or process could be modelled at an abstract level by extracting common qualities from specific examples.The process of formulating generalized concepts enables a better understanding of complex issues and, consequentially, the resolution of complex problems.

Therefore, modelling starts with the use of abstraction for the understanding of the problem and the use of methodologies and techniques for the implementation aspects.

A model has three essential parts:

(i) a process or phenomenon which is to be modeled,

(ii) a mathematical structure capable of expressing the important properties of the process to be modeled, and
(iii) an explicit correspondence between the two.

The first part of a model is a phenomenon or a process which is to be characterized mathematically. For example the execution of a program, the allocation of resources of a computation center, and the flow of information in a computer network. The real world component is described quantitatively by such things as parameters values each times the event occur.

The second part of a model is an abstract mathematical structure. The structure has no intrinsic relation to the real world. However, because of its abstractness, the structure can be used to model many different phenomena. Therefore, if the mathematical model is successful, the language of its mathematical structure can be used to make assertions about the object being modeled.

The third part of a model is a specification of the way in which the real world is represented by a mathematical structure, i.e., a correspondence between the elements of the first component and those of the second. Parameters, relationships, and occurences in the real world will be associated with such variables, equations, and operations in the mathematical structure. This correspondence makes possible the use of the mathematical structure to describe those facets of the real world which are of interest.

Visualizing Processes

2007-03-07T11:11:00.002+01:00

Visualizing processes and how to project them it's not an easy task. A structured approach is needed for capturing and document this information.

Each process has to have a purpose, entry criteria that triggers it, input(s), tasks (a list of actions bringing the results), output(s), work aids (there might be functionalities to support the process), and a criteria for exiting the process. This structured approach is ususally outlined on a template and serves as a guide for analysis purposes.

Organizational Structures - Team

2007-01-25T07:41:00.002+01:00

This type of organization focuses all resources on projects. Many organizations today establish cross functional task force teams to handle strategic and crucial projects.

These teams are an example of a project team organization structure. Typically resources are assigned full time to a project and they form the core team. The core team is supplemented with other expertise on an as needed basis.

The role of the functional manager is eliminated or they act as internal technical consultants to the project team, and the project manager is responsible for the project budget, scope, schedule and all other resource, contractual and customer issues.

This type of organizational structure is suitable for fixed price fixed time contracts. Organizations that adopt this kind of organization structures will need to insure that their financial and other corporate systems are setup for project data collection and reporting.

Ideally project managers should have the authority to hire outside consultants or resources to keep the project on track.

Organizational Structures - Matrix

2007-01-25T07:23:00.002+01:00

In this type of organization structure resources are still grouped by their functional skills, however work is primarily done through projects and a single point of contact (project manager / project coordinator) for each project is established.

Ideally, the project managers are grouped in a separate unit or department and they are responsible for the successful delivery of projects from concept to product release. Resources working on projects in a matrix environment report to their functional line manager as well as to the project manager for their project. This can become a source of conflict as the functional manager views their own role as being responsible for the work of their resources across all projects, while the project manager is responsible for a specific project.

With multiple project assignments resource’s priorities can shift as they are now assigned to more than one project at the same time. Establishing clear roles and responsibilities for functional and project managers is important for the better utilization of this type of organization structure.

The matrix organization is suitable for large projects that require significant cross-functional resources, and with a project manager in charge, there is a better overall project communications. This type of structure can foster better project resource team spirit. To run projects efficiently in a matrix organization, project managers should own the project budget and should be able to plan for and communicate in advance resource requirements.

Organizational Structures - Functional

2007-01-25T07:18:00.001+01:00

In this type of organization structure resources are grouped into functional specific units or departments based on their functional and or technical skills, and are excellent for operation (on going) type activities and they are also useful for managing small projects where the majority of the technical work is done within the same unit.

These types of organization structures, fall short in terms of timely delivery in a situation that requires extensive cross functional communication and cooperation. There s a chance of failure due to the lack of project ownership as resources in general will view their part of the project as part of their regular work and once they are done with their part they have nothing to do with the project. The project leader has little or no authority over resources outside of his / her department or unit.

Project Environment

2007-01-24T06:59:00.001+01:00

For a project to be successful, there's a need to define its environment in terms of organizational structures, project classifications, portfolio project management, resource commitment, ...

Project Management Life Cycle

2007-01-21T18:57:00.002+01:00

Project management as a function has its own distinct processes typified by the life cycle chart.

Planning is erroneously perceived as a phase in project management. This would be true only if one could freeze the change on all five-project variables (time, scope, quality, resources, budget). Under such a scenario, projects can be planned once, up front and the outcome (the project plan) followed to the completion of the project. Since this is rare if not quite impossible in real life, it does make sense to say that where there is change there is a definite need to revamp the project plan to incorporate or deflect the changes, thus reflecting reality. In other words, planning is an iterative process, which is on going through out the life of the project. The format and degree of detail in planning is a function of the size and complexity of the project and the degree of control required.

During the execution process, monitoring project performance is crucial to the project. It represents the vehicle for capturing progress, measuring variances and change through out the life of the project. Proper project management requires the development and implementation of project specific monitoring processes and procedures to be utilized when managing a project.

Control is the decision making mechanisms available in an Organization that can be brought to bear on a project to address problems and issues as they arise to insure a successful delivery of the project goals and objectives. Control can be established utilizing a combination of specific formal and non-formal meetings (status, progress reporting and product reviews etc.).

Closing the project includes a set of policies and procedures that need to be defined to close a project, archive it and obtain end user acceptance and sign off.

Project Manager's Role

2007-01-21T18:19:00.001+01:00

What do you think the role of the project manager is in your organization?

Project Variables

2007-01-21T09:37:00.004+01:00

In a project environment it's possible to identify variables that are inter-related and can impact the success of a project. The degree of flexibility for each variable is different from one project to another. They also could vary on the same project depending on the phase of the project or its status. Example of variables are:

Scope

The amount of work to be done represented by all the activities in the project plan.

Time

The established time frame for executing the project represented by the time elapsed between the defined start and end date of the project deliverables.

Cost

The project budget and /or available funding for the project.

Resources

People, materials and equipment necessary to deliver the project.

Quality

The performance capability, which meets or exceeds the end user expectation.

Project management is the art and science of measuring, analyzing and managing the change in a project represented by these variables. Every person involved in a project whether they are managers, project leaders, contractors, vendors, project team members and owners should understand and appreciate the degree of flexibility available at all times. As part of the project planning process, the project manager should conduct a project variable and priority status discussion, to insure all project participants are fully aware of the constraints and flexibility in their project environment.

The differences between Project, Operation and Program

2007-01-21T07:42:00.002+01:00

We said that a project is defined as a temporary endeavor that consumes resources, incurs cost and produce deliverables over a finite period of time to achieve a specific goal. They come in all shapes and sizes and can vary in length or complexity.

Operation type activities are similar to project activities in that they too produce deliverables, consume resources and incur cost. However they are on-going or repetitive in nature, hence they are not project activities or tasks. Some examples of operation activities are weekly maintenance of databases, paying invoices or help desk operations activities.

Programs are much larger than projects. They are made up of many projects and on going activities such as operation type activities and are similar to projects as they consume resources, incur cost and produce deliverables. However programs are more complex and include repetitive operation type activities such as maintenance work, facility administration etc, and are funded typically on a fiscal year basis.

Projects in general are more time focused than programs.

Project behaviour during lifecycle

2007-01-18T09:25:00.004+01:00

What is the behaviour of the curve during different time intervals, such as at (0), (0, 20-30%], (20-30%, 50%], (50%, 75%], and (75%, 100].

Brief analysis and points of discussion:

Since a project has a temporary endeavor, the timeframe has to be finite. The broken lines in the graph represent finite areas such as phases or milestones. The black graph represents the estimated project plan schedule, the blue graph represents an early schedule, and the red graph represents a lagging schedule.

In an ideal situation the beginning is usually slow because people need to acquire confidence with the project, and once the schedule has achieved 20-30% of the work completed, the slope of the graph will change and will accelerate due to the confidence and knowledge acquired. At 70-80% the schedule has reached a very good level of control and will continue with confidence to full completion of the project.

What is the scenario before Time=0, i.e., before launching of the project?

In practice, most organizations don't really start from scratch when launching a project. Some pre-analysis work has been done in order to get an idea of what has to be done in terms of requirements, characteristics and resources needed for the project. With this information (although it's at high level), it's possible to make an estimation of the time and cost; decisions are usually taken after this information is available (or at least we reach a confidence level of 80%). The realization of a successful project will require commitments from the operating organization and all stakeholders.

Thinking how to proceed with topics on project management ...

2007-01-15T16:19:00.001+01:00

Thinking how to graphically represent the typical behavior of a project.

Defining a project

2007-01-15T12:48:00.003+01:00

A project is something that has a temporary endeavor, has unique activities, has defined deliverables, consumes resources, incurs cost, ...

Why do we need to implement project management?

2007-01-15T10:44:00.001+01:00

Implementing project management means having knowledge of all processes, techniques, and methods that govern the lifecycle of a project.

As a consequence, we are able to:

-Meet the customer’s expectation
-Meet project deadlines and accountability
-Manage project profit margins
-Efficient resource utilization
-Manage information for faster decision making

Start of my discussion on Project and Program Management

2007-01-14T19:21:00.001+01:00

Projects are initiated in response to a problem or to take advantage of an opportunity. They are defined as a temporary endeavor that consumes resources, incurs cost and produce deliverables over a finite period of time to achieve a specific goal. Projects come in all shapes and sizes. They can vary in length or complexity, but the above mentioned definition of a project holds true for all of them.

Listed here are examples of projects:

-Organizational Process Re-Engineering

-Relocation Of Facilities & Equipment

-Designing A Web Enabled Systems

-Developing New or Enhancing Existing Products

-Migration from mainframe to a windows-based distributed client-server system

Project management is the art and science of planning, controlling and tracking of activities and resources to achieve the organization’s strategic and business objectives.

PROCESS - DESCRIPTION	Family	Indicators	Metrics	Measurement criteria	Source
PROCESS A	Quality	Customer Satisfaction	Degree of success	Satisfaction level of the request/change	SLA (Service Level Agreement)
PROCESS A	Efficiency	Delivery Time	Time	Evaluation of the response time / delivery	Response / Specifications

LEFF	Quality	Efficiency
= 1	Requests were satisfied as established in the SLA.	Requests were satisfied as established in the SLA.
< 1	Requests were not satisfied.	Requests were not satisfied.
> 1	Requests were satisfied and expectation exceeded.	Requests were satisfied and expectation exceeded.