Process Management vs Project Management

Process Management and Project Management go hand-in-hand to deliver a successful project. Both are critical components of Gartner’s Application Development Management Continuum (Gartner Group, 1995). Each has a clearly delineated area of responsibility.

Process Management deals with defining and managing what is done on a project, including tasks completed, deliverables produced, roles performed, and tools used. It deals with the “scientific method” used to deliver an IT solution.

Project Management deals with tracking the process being executed, from a schedule and cost perspective. It includes functions for developing the optimal project schedule, producing a financial model of the project, scheduling and tracking of effort against plan, managing costs against budget, and reporting of status, to name a few.

I will be spending the next several posts focusing on Process Management; however, some of the Process Management tools it describes are used for both Process Management and Project Management.

Process Management Objectives

By defining and applying a scientific method to the delivery of IT solutions, Process Management has the following objectives:

� To define a repeatable process that, when executed, behaves predictably and delivers a quality product – on schedule and within budget.

� To produce higher quality IT solutions.

� To increase productivity and shorten the delivery cycle, through the application of optimized processes and the re-use of work products.

� To upgrade the skill levels of all project participants, including delivery team staff and customers.

By: The Great Sir Craig

Process Management vs Knowledge-Driven Process Management

Specification Reinspection Correction Time: This describes the effort required to correct defects found during the reinspection of a specification deliverable. Typically specification deliverables include the Requirements Definition, Functional Design, Structural Design, and System Test Specification. The correction effort is influenced by the complexity of the specification deliverable. http://preview.tinyurl.com/4ty4rf

______________________________________________________________________________________________

Process management involves two dimensions:

1. defining and continually refining a set of procedures for the management of repeatable business processes; and

2. executing and monitoring the processes.

Process management disciplines are applied by managers in most business contexts, including Project Managers who use these disciplines to control and monitor the execution of project tasks with timely and accurate information. Process and Project Management overlap in a number of areas but do not have the same focus.

Knowledge-Driven Process Management is the automation of Process Management through the application of a defined process. The process is defined in a knowledge repository or rule-based engine (e.g., an expert system) and drives an integrated suite of workflow management, project management, and product delivery tools.

Knowledge-Driven Process Management presents the worker with a step by step process and business rules for performing work; invokes the tools required to perform the work; provides templates, checklists, and samples for the work to be performed; and supplies in a pro-active manner procedural information on how to perform each specific task. It also provides information about the processes being performed:

1. to support coordination of tasks assigned to individuals; and

2. to provide status about activities relative to plans or defined performance measures.

CHECKLIST FOR MANAGING TEAM PERFORMANCE

This checklist given below can provide some guidance on ensuring that the foundations for performance are properly laid for any team.  It also hints at items to watch within an organization that may impact the team.

CHECKLIST FOR MANAGING TEAM PERFORMANCE
	Yes	No	N/A	Remarks
Are standards and procedures in place covering the general conduct of the team (e.g., project terminology, routine communications, meeting procedures)?
Have all team members received a full and sufficient orientation to the project?
Are all team members adequately trained to carry out their responsibilities?
Does the management style encourage respect for the individual and generate personal focus and clear intent to achieve customer satisfaction?
Are all team member roles and responsibilities clearly defined and understood?
Have project and personal objectives been clearly defined for each team member?
Do team members interact effectively?
Is there personal and collective display of excitement and interest?
Are the right people making the decisions based on sources of information rather than position in the hierarchy?
Is everyone able to influence decision-making and understand the results?
Are team leaders consulting team members for their opinions, encouraging them, and coaching them on the right way to do things, in such a way that they maintain confidence in their ability to meet their delivery commitments?
Are the team communications effective, including all members not just senior levels?
Does the team meet regularly to review status, share experiences, provide suggestions, and resolve problems and concerns?
Are project meetings run effectively (and is meeting time properly managed)?
Is project and company information posted/circulated?
Is everyone committed to understanding the issues and opportunities in problem situations and developing effective plans to achieve or resolve them?
Is there evidence of positive morale and teamwork?
Is the productivity of the team at an optimum level?
Are the project workspace and facilities appropriate?
Has the project implemented some means to recognize and reward quality service, creativity, innovation, and success (can be as simple as public acknowledgement and thanks for a job well-done)?
Does the environment encourage creative dissonance and continual striving for improvement within the cost and schedule constraints?
Are performance reviews being conducted to record and communicate the accomplishments of team members, and to appraise their skills, to facilitate career development?
Is project overtime within acceptable limits?
Is turnover within acceptable limits?
For longer term projects, are people being rotated off the project, or into new roles on the project, in a 12 to 18 month timeframe, in accordance with the staff rotation plan?

Sir Craig

Why your meetings suck!

he art and craft of executing good meetings has been completely lost from the business landscape.  Both the private and public sectors are a complete wasteland of time wasting, soul sucking bad meetings.  It needs to stop!

A number of years ago, I made a few changes to my operational parameters which actually cleared up a lot the time I’ve spent wasting away in completely pointless meetings.  If I walk out of a meeting thinking that nothing has been accomplished, there is a problem.  I work very hard to plan and execute my meetings – it isn’t too much to ask others to do the same.

I never accept any meeting booking that doesn’t include some form of an agenda. The offer of an agenda at the start of a meeting also doesn’t cut it.  I cannot be prepared for a meeting if I don’t know the content and purpose of a meeting ahead of time.  The fact that no agenda exists ahead of time tells me right away that there is no plan for the meeting, no purpose to accomplish anything and that I should avoid it completely.  Declined.

The other complete waste of time is the supposed “status meetings”.  Waste of time.  Status is for reporting – NOT MEETING.  If you can’t have a team complete status reports on what they have done and what their issues are – get a new team.  Even if there is an agenda – I never go to meetings that include status in the title.  Project managers that operate with status meetings should simply be taken to the middle of a desert, shot in both knees and left for dead.  9 times out of 10 the other members of the meeting are not interested in my status report any more than I am interested in theirs.  Assembling everyone to listen to them is a complete waste of everyone’s time. Don’t ever do this. There is only one reason a project manager should use a status meeting – he doesn’t know how to read. If you have a functional illiterate as a project manager on your project – my heart goes out to you.

A meeting is any kind of purposeful coming together of people to carry out the business of the company such as communications, planning, setting policy, making decisions, or motivating a team. To be effective, these meetings need to be well planned and executed.   Good meetings bring forth the best in people – the best ideas, the best decisions, and the best follow-up reactions. Not all meetings are good meetings, but good meetings can happen, and when they do, the company and the individual participants reap the benefits.

Bringing together large groups to brainstorm the content of a document? Supreme waste of time.

Small groups to perform brainstorming of the skeleton of a document and then assigning an individual to create the initial draft of the document to use as a straw-man at a larger meeting – useful.  Providing a copy of the draft to participants several days in advance and doing a summary presentation of the draft to the group – even better.

Regardless of the meetings purpose – always have an agenda and release it ahead of time.  There is no bigger waste of peoples time than getting together for a meeting that nobody knows the purpose of nor was able to prepare for.  Nothing worse than sitting with a group of people that have just had a topic dropped on them, watching them think of all the things that they could have read or referenced to be prepared for that topic and then muddle through a meeting about it.

One of the things that I have tried to do with some of my entries, is explain methods and provide useful tools to guide meetings. An example is the groups of questionnaires I provided for driving interviews on various types of technical projects.  I will try to provide more in the future for other types of meetings that continue to be executed poorly.

Here is Sue Pelletier’s Top 10 reasons to bolt from a meeting.  Some good resources on running better meetings – which should mean less meetings – can be found here and here.

The best way to stop bad meetings is to stop going to bad meetings – don’t waste your time!

Sophos knows...

http://www.snowwhitetest.com/press/

By Sir Craig

Rule of Thumb: Project Mgmt & Support Effort

The percentage of total effort applied to project management and support activities is between 12 to 18 percent. This rule of thumb provides a reasonableness check of the project management and support effort, considering the total project effort.

---

Source

This rule of thumb is based on Capers Jones analysis of the distribution of effort experienced on over 1300 software projects, as cited in Applied Software Measurement.

Assumptions

Management and support activities include the effort of the project management staff (e.g., Project Director, Deputy Project Director, Project Manager, and Team Leader) as well as Project Management Specialists and secretarial support.

Tips and Hints

Management and support effort increases as the size of the project increases. A small project (e.g., from 25 to 50 person months) will require approximately 12 percent of total project effort; a large project (around 6,500 person months) will require approximately 18 percent of total project effort.

Other factors can affect the percentage of project management and support effort required, such as specific customer requirements, the political organization, and the skills and experience of the project team.

Example

Assume a total project effort of 64 person months (or 1,216 person days) of effort. Thirteen percent of the total effort is 158 person days.

References

Jones, Capers. 1991. Applied Software Measurement: Assuring Productivity and Quality. New York, NY: McGraw-Hill, Inc. ISBN: 0-07-032813-7. Craig (Chief Technology Tactician)

Association Matrix Checklist

CHECKLIST FOR AN ASSOCIATION MATRIX
Project Name:		Project Code:
Document Name:		Document Number:
Reviewed By:		Reviewed Date:
Checklist Items		Yes	No	Comments
There are no missing rows or columns (the matrix is complete).
The rows and columns are sorted for best presentation.
All rows have an association with at least one column.
All columns have an association with at least one row.
For CRUD matrices, all entities that are being managed by the application have a "create".
For CRUD matrices, all entities that are managed by other applications (i.e., interfaces) show as "read" only.

i have to face problems, and solve them.

Reality

Reality of Life

Life isn't just full of happiness,
It's sunsets, it's love, it's tears.
It's the thoughts of yesterdays memories,
That can wash away all out fears.

It's that very painful experience,
That each one of us has had.
It's the laughter that fills the air,
It's the tears when you are sad.

It's loving that someone special,
That at one time made you smile.
It's the pain of losing that person,
But the memories that make it worthwhile.

It's that child in every one of us,
Although in time we'll all be old.
It's the good times we'll never forget,
It's the memories we'll always hold.

It's the hug that we all need,
When we'd rather drown in our sorrow.
It's the hope in every one of us,
That makes us hold on for tomorrow.

Using CRUD Diagrams to Group Processes into Systems

Using CRUD Diagrams to Group Processes into Systems

Grouping or clustering processes allows the analyst to identify what business processes fit naturally together. The groupings help determine what functions a specific system should perform and what data it requires.

The objective is for groups to have a high degree of independence from one another.

Converting to Association Matrix may Simplify Grouping

Grouping processes does not distinguish between create, read, update, or delete. Therefore, it may be simpler to convert the CRUD Diagram to an Association Matrix by changing each intersection with a C, R, U, and/or D into a common symbol such as a check mark or an asterisk.

Example: CRUD Diagram Converted to Association Matrix

Entity Process	Customer	Customer Order	Customer Account	Customer Invoice	Vendor Invoice	Product
Receive Customer Order	*	*	*
Process Customer Order	*		*			*
Fill Customer Order	*		*			*
Maintain Customer Account	*		*		*
Terminate Customer Account	*		*		*
Pay Vendor Invoices					*
Validate Vendor Invoices					*
Pay Vendor Invoices					*
Invoice Customer	*		*	*
Maintain Inventory						*

Initial Grouping

Begin by identifying the first two processes that use the same data entities. Rearrange the rows to position these two processes at the top of the matrix.

Identify other processes that use the same data entities and, if any, move them into the next rows in the matrix.

Example: Initial Grouping of Processes

Entity Process	Customer	Customer Order	Customer Account	Customer Invoice	Vendor Invoice	Product
Maintain Customer Account	*		*
Terminate Customer Account	*		*
Receive Customer Order	*	*	*
Process Customer Order	*		*			*
Fill Customer Order	*		*			*
Ship Customer Order			*		*
Validate Vendor Invoices					*
Pay Vendor Invoices					*
Invoice Customer	*		*	*
Maintain Inventory						*

Continue Grouping Process

Continue to identify other sets of processes that share the same data entities and move them into the next rows.

Example: Next Grouping of Processes

Entity Process	Customer	Customer Order	Customer Account	Customer Invoice	Vendor Invoice	Product
Maintain Customer Account	*		*
Terminate Customer Account	*		*
Process Customer Order	*		*			*
Fill Customer Order	*		*			*
Validate Vendor Invoices					*
Pay Vendor Invoices					*
Receive Customer Order	*	*	*
Ship Customer Order			*		*
Invoice Customer	*		*	*
Maintain Inventory						*

Manual Grouping

Once all processes that use the same entities have been identified, begin to analyze remaining entities to determine their best fit. This analysis is subjective. In the example you may decide that Receive Customer Order and Invoice Customer should be grouped with Process Customer Order and Fill Customer Order because they are all involved in processing the customer's order.

Example: Manual Grouping of Processes

Entity Process	Customer	Customer Order	Customer Account	Customer Invoice	Vendor Invoice	Product
Maintain Customer Account	*		*
Terminate Customer Account	*		*
Receive Customer Order	*	*	*
Process Customer Order	*		*			*
Fill Customer Order	*		*			*
Invoice Customer	*		*	*
Ship Customer Order			*		*
Validate Vendor Invoices					*
Pay Vendor Invoices					*
Maintain Inventory						*

Consider Using Subject Databases

Entities may be grouped into subject databases using a method such as Affinity Analysis. The subject databases are then used on the matrix instead of data entities. Grouping processes will be easier when there are fewer objects to analyze. For example, Customer, Customer Order, and Customer Account may be grouped as Customer while Customer Invoice and Vendor Invoice may be grouped as Invoicing.

Example: Grouping Processes using Subject Databases

Subject Process	Customer	Invoicing	Product
Maintain Customer Account	*
Terminate Customer Account	*
Receive Customer Order	*
Process Customer Order	*		*
Fill Customer Order	*		*
Invoice Customer	*	*
Ship Customer Order	*	*
Validate Vendor Invoices		*
Pay Vendor Invoices		*
Maintain Inventory			*

Craig Borysowich (Chief Technology Tactician)

what did you say

Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye
Bewafa Hum Nahin
Bewafa Tum Nahin
To Kyon Itne Gile Ho Gaye
Chalte Chalte Kaise Yeh Faasle Ho Gaye
Kya Pata Kahan Hum Chale
Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye
Bewafa Hum Nahin
Bewafa Tum Nahin
To Kyon Itne Gile Ho Gaye
Chalte Chalte Kaise Yeh Faasle Ho Gaye
Kya Pata Kahan Hum Chale

Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye
Bewafa Hum Nahin
Bewafa Tum Nahin
To Kyon Itne Gile Ho Gaye
Chalte Chalte Kaise Yeh Faasle Ho Gaye
Kya Pata Kahan Hum Chale

Duniya Jo Pooche To Kya Hum Kahen
Koi Yeh Humko Samjaade
Thes Lagi To Pal Mein Toot Gaye
Sheshe Ke The Kya Sab Vaade
Jaata Hai Koi Kyon Sapno Ko Thukraake
Payega Yeh Dil Kya Kisi Ko Batake
Chalte Chalte Raakh Hum Bin Jale Ho Gaye
Bujh Gaye Diye Pyaar Ke
Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye

Doob Gaya Hai Kaise Dard Mein Dil
Aansoon Bhari Hai Ab Aankhen
Tanhaiyon Ki Jo Ruth Aa Gayi
Ujdi Hui Hai Sab Raahein
Socha Tha Paayenge Dono Ek Manzil Ko
Raahein Jo Badli To Tumhi Batado
Chalte Chalte Gum Kahan Kaple Ho Gaye
Kho Gaye Kahan Raste
Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye
Bewafa Hum Nahin
Bewafa Tum Nahin
To Kyon Itne Gile Ho Gaye
Chalte Chalte Kaise Yeh Faasle Ho Gaye
Kya Pata Kahan Hum Chale
Kya Pata Kahan Hum Chale

Do I Even Need a Prototype??? & Prototyping Overview

Prototypes can add unnecessary overhead if they are not needed or are not workable for a particular project situation. Analyze the circumstances of the project to determine if a prototype will add value. When making the decision, consider the benefits of prototyping.

THE BENEFITS OF PROTOTYPING

Types of Benefits

Prototyping primarily assists with communication between the end-user and the development staff. The enhanced communication results in greater accuracy and fewer errors in later parts of the project, when they become more expensive to fix. The early involvement also empowers the end-user and facilitates system acceptance and understanding.

Communicate Requirements to Customer

Prototyping is an effective means of communicating the analyst's understanding of system requirements to the customer. The customer achieves a better understanding of the proposed system than could be obtained from written documentation alone. Therefore, problems that may have gone undetected until a later stage are identified earlier.

Prototyping should be used for all interactive systems. Consider that a serious review by end-users will almost always result in a change.

Communicate Requirements to Programmer

Prototyping is an effective means of communicating the system requirements and design to programmers. It is easier for the programmers to build a system from a working model than from a design document.

Customers See the Design at an Earlier Stage

Some design activities, such as Human Interface Design, occur at an earlier stage in the life cycle when a prototype is developed. Customers are able to try out the design and provide their input before much time and money are expended.

If Horizontal Prototyping is used during analysis, a first cut of the system externals is defined at that time. If a Vertical Prototype is developed, a first cut of the database must be designed during analysis.

Prototyping can greatly reduce the scope and size of design activities. Design activities still occur but they are moved to other stages of the system life cycle. Depending on the extent of the prototype, design efforts can be reduced to include only such tasks as test plan preparation, user aids design, conversion design, and database optimization.

Greater Customer Involvement

Customers become more involved in the system development process when a prototype is used. This helps ensure that customer requirements are met.

Reduce Written Documentation

Prototyping makes a system more intuitive and reduces the amount of written documentation required.

Situation Where Prototypes are Most Valuable

Some situations where prototyping is particularly valuable include:

· scope of the project permits customer involvement to improve the system,

· customers are unsure of their exact requirements or are having difficulty expressing requirements,

· the new system is altering a basic business operation,

· customers are not fully aware of all the impacts of the new system,

· the advantages and disadvantages of alternative solutions need to be explored.

Situations For Limited Prototyping

In general, prototyping is more valuable for on-line systems than for batch processing. However, most batch systems produce reports which can be prototyped using a report generator. Prototyping is of limited value in some systems that are logic intensive. In these cases, horizontal prototypes can still be used to evaluate the human interface.

Craig Borysowich (Chief Technology Tactician)

-------------------------------------------------------------------------------------

Use Prototyping to:

· develop a working model of key functional components of a system, which may or may not be developed into the final system,

· enhance communication of requirements between the analyst, customer, and development team members,

· demonstrate features of the proposed system to such a level that the customer can relate it to his or her requirements,

· allow customers and analysts to explore alternative architectures and specific customer task scenarios,

· uncover design flaws early in the project life cycle,

· train customers who will eventually use the system,

· validate customer requirements (are we building the right product?),

· verify customer requirements (are we building the product right?).

Method

To build a prototype, complete the following steps:

Evaluate the Need for Prototyping

Define the Type of Prototype

Develop the Prototype

Refine the Prototype

Tips and Hints

Fourth Generation tools make it possible to quickly and easily prototype a model of system externals. However, if the prototype cannot be built and changed easily, many of the advantages of prototyping are lost. Some tools require considerable effort to set up the database or make database changes, particularly in the hands of inexperienced programmers.

See Also

Interviewing (for defining requirements related to the external design of a system)

Participant Observation (for defining requirements related to the external design of a system)

Timeboxing

Craig Borysowich (Chief Technology Tactician)