Sunday, January 20, 2013

Project Management is simply Risk Management

 
When you think about the project management, is it simply comes to you as risk management ? Why risk is so important to any project ?  To project manager, in my view, RISK MANAGEMENT is simply PROJECT MANAGEMENT.
 
Question you have to ask,
 
If project management is robust in the organisation ? There is big chance of failing project, you can call as intrinsic risk but really can bother much in day today project execution.

If people managing it as adhoc processes ? You need to have a specialist here to manage complex project.

If stakeholder buy your reporting ? If reporting is understood by stakeholders e.g. your sponsors, users, board and management.

If project manager foresee the future ? If project manager can see the end as soon as he has analysed project with team and baselined the project first time ? What I mean by "Seeing the future" is project manager always know what it takes to complete the project (since first baseline), as if he is having divine power to predict the end of the project. There could be many changes d1`own the line e.g. scope changes, resignations, cost issues, quality etc. etc. but project manager should always be in control to capture these details from team and provide "What it takes to complete the project". Various technique can be used example EVM - Earned value management, Critical path Analysis, etc. to drive the new baseline or to attain current plan in spite of myriad of changes.

Is enough is done to see the end of project ?   When we start the project there should be proper analysis WBS/PBS ( Work Breakdown Structure and Product Breakdown structure), analysis, sequencing and architecting to come to solution as broader level.  

As soon as we are assigned a project we as team see what are factor which will stop us to realise the business goal of the project. They become part of risk log. Risk could be simply "proper project planning is not done" i.e. Many areas were not uncovered or not understood.

So in a way if project is very simple you can manage it as activity with little planning as risk is low, but when it comes to big project you need to manage each  knowledge areas carefully (namely cost, scope, schedule, quality, human, procurement, stakeholder, communication and integration) otherwise they will create risk to your project success. Risk is like envolve which hold these knowledge areas and you have to keep opening your skills of these based on your risks.



Change Working time in MS project 2010


Change Working time in MS project 2010


This is simple trick to change the day/time from non working to working day/time (vice versa) of your MSproject calendar e.g. if Saturday is normally non working day for you but one Saturday you have to come office exceptionally (as it is end of year to complete some task of the the project). So we can make this day as working day. In normal project plan MS project will schedule the task not on the weekend.


Following are steps.

1. Open your MS Project.

2. Go to Tools.

3. Click on the Change Working Time (to make as working day). Following screen will display.

 

4. In the exception tab, provide the name, Start date and Finish date.

 

5. Details button will be enabled once you fill in the line for the date. Input the time there to indicate that what time to what time you are working. From and To. Auto suggestion will come when you choose Working times:

See also the background the Saturday and Sunday Bar which is currently two rows for the date of 27 Jan 2013.
 
 
 
 
6. Click OK on current screen and again click OK on the background screen when visible.
 
7. See the screen below.  So Sunday 27 Jan 2013 becomes working day.
 
 



In this way you can make days to working day from Non working in any specific calendar. Hope you have learnt new trick today for the MS Project.


 

Thursday, December 15, 2011

Street Smart Project Management - PMP Vs PRINCE2 Vs AGILE


There is always lot of debate on the project management practice, why projects are failing and how it can be pulled back from delays etc. I will share some of the point which can help to better manage large project in complex organization where organization is matrix based and resources are shared. I will also highlight the value shared by different methodology like PMP, PRINCE2 and AGILE Project Management. Project Manager should be street-smart at the end to engage each of good elements to get desired results.

1.    PRINCE2 is Project Management by exception: In PRINCE2 Project Management, an implication of Management by Exception is that the project board should meet when key decisions about the project should be taken, and not on regular intervals. The Project Manager should produce an Exception Report to ask the board for meetings. "Management by Exception is a policy by which management devotes it’s time to investigating only those situations in which actual results differ significantly from planned results. The idea is that management should spend its valuable time concentrating on the more important items (such as shaping the company's future strategic course). Attention is given only to material deviations requiring investigation.

2.    PRINCE2 is best techniques which makes management Accountable for project success & failure (Not a joke, you need their blessings) this always have better chances to succeed. Ultimately project manager want to be successful manager with less head breaking pain.  Provided money and resources project manager can do wonders, but think when you have organization where you are not the direct manager and asking people to engage on your project could not be easy. One of the best part of PRINCE2, it gives an organization where project manager is only responsible and project is delegated to him by project board (comprising of suppliers – who will ensures skilled & requested resources are present to execute the project, Senior users – Right requirements are given and Executive-Chairman of the board who can intervene when required and also help to resolve conflicts). Board is accountable for the project and it would be best interest of the board (Management) to get the resource and money to get desired results.

3.    Being agile at beginning of big project does not help in big projects. When you start project we should have bird eyes view and it should have less interconnections, do not try to do everything from first day. With large enterprise project we should not have Tunnel Vision which will haunt at the end. Remember It is difficult & thousand times costlier to fix up the system later.  Many instance non functional requirements are easily getting ignored because they have no direct impact on user experience. Most of the time agile mechanics are time boxed which should not be the case in the beginning. It is expensive mistake although being advocated to be good practice by agile practitioner.

4.    Being agile at end of the big or small projects does help a lot. Why? At the end you have integrated system where things works in several ways and it is not easy to visualize at beginning by customer and you. You should be ready to adjust the thing which gives integrity and business value to the users. Last one month (I will say 5-15% of duration project timeline) development team and users should work in together with users to weed out problems. Being agile or doing agile project management has many definitions. In simplest form I will define it as “Being Proactive as one Team - Customer and Developer.

5.    People who challenge most could have major stake in side project. As project manager you should outsmart them by doing better. Take note of all that what they wish, try to work on it. Make them accountable in board as early as possible so that they provide enough support or provide means for solution.


6.    Use EVM technique for large project to clearly show to management for the progress and value earned by project overtime. EVM integrates the areas of performance, schedule, and actual cost to provide metrics for work actually accomplished. Earned value (EV) Show the efficiency how the project is managed and give better picture of performance than SV and CV which are outdated.

7.   To my view below are the value shared by different methodology like PMP, PRINCE2 and AGILE Project management.

Values
PMI
PRINCE2
Agile
Management by Exception
**
*****
*
Being Agile
***
***
*****
Cost Accountability
****
****
*
Timeline
***
****
**
Quality
****
****
***
Earned value management
****
****
**








Please help to share your thoughts to discuss this.




Friday, October 26, 2007

Inspections review in software Development Project

An Inspection review is a formal verification technique in which software life cycle work products are examined in details by group of peers for explicit purpose of detecting and identifying the defects। Software Inspections are a rigorous form of peer reviews, a Key Process Area for improvement. It is one of the best technique among the different peer review techniques (e.g. Buddy checks, circulation review, Technical review, Walkthroughs etc.) to detect the defect effectively. Peer Reviews on the software lifecycle work products indicate the quality of the evolving system each step on the way, increasing dramatically the probability of the highest quality product being delivered.

2. Value of implementing inspections review for organizations
I. Effective peer reviews of all types of software work products are essential if software development organizations are to reduce their cost of producing software. Formal inspections of requirements specifications, designs, source code, and other work products are a proven means for finding errors and improving the quality of software products.
II. ROI of Software Inspection Review Process: Benefit/cost ratio for Software Inspection Review is statistically 34:1 and ROI is 3000%. Software Inspection is one of the most crucial SPI to generate ROI for company in term of reduced cost, of development and maintenance, statistically analyzed by David F. Rico on several project Data. (Book Ref: ROI of Software Process Improvement)
III. Minimal defect correction backlash at systems integration time.
IV. Peer Reviews aim to minimize the number of defects being passed along from one segment to the next, by finding and fixing the defects in the segment in which they were created.
a. 23% increase in coding productivity
b. 25% reduction of schedule plans
c. Each major defect found at inspection saves an average of nine hours of correction time later.
d. Up front costs are outweighed by benefit.
V. The role of inspection in software development process is not only directed to detect and correct faults as early as possible. It is a method for measuring and controlling the whole development process, and the way to predict and prevent faults in later phases.
a. The process is led by a moderator who is not the author and is impartial to the life-cycle work product under review.
b. Defect resolution is mandatory (performed off-line) and rework is formally verified.
c. Improvement in consequent product quality
VI. According to the IBM analysis Inspection reviews is most effective technique for detect Errors and defect removal. It effectiveness in term of percentage is 60-70%.
VII. Post-implementation maintenance costs can be reduced by ~50% with formal inspection reviews.
VIII. Data is analyzed to improve the product, the process and the effectiveness of the inspection process. This is added value to the organization in term of Maturity of the process (SEI’s Capability Maturity Model-Key Process Area).
a. Defect data is systematically collected and stored in an inspection database.
b. Data is analyzed to improve the product, the process and the effectiveness of the inspection process
c. Focus is on continuous quantitative improvement and also process is measured and controlled.
IX. At the first glance they may look very time consuming. But statistical evaluations have shown that over the whole life cycle of the software development they even save resources and thus money and improve the quality of the product. Refer the diagram below.

In all Peer Review are integral elements of a quality system, which bring high tangible and intangible benefits to organizations and Inspection review is best way to realize the benefits. They are known to deliver high economic value.




Google






















Saturday, July 7, 2007

First thought on Enhancement Project Function Point

Its exam time I am very perplexed if tomorrow i go to office and my client ask me to add new column in all the datafile of the project as following.

* Creataion Date
* Last Updated date
* Also show it on the screen the creation date and last Updated date.
* May be in report also cleint want to see these dates.


What is the estimate of FPC of this enhancement project. I assume its as good as developing the project from Scratch.

Also the adjustment factors remains the same.

I think We need some revision of the FPC for the enhancement project as its bit not realistic. It really very much over over exaggeration of the Fact that Changes are unrealistic.

Other fact that the adjustment factor also doesn't change. it is assumed to be the original value. Now if client argues that we never change any thing here.

What we can say....multiply by (.65) in this case !! Its true that we are doing nothing in this case. Enhancement adjustment factor as it is automatically taken care by the original project.

But still factor remain toooooo high. what is your thought, how we can we realistic about this ?

Monday, June 11, 2007

Zero Defect Software

ZeroDefect@Software We want to realize this...The ultimate truth of universe where there is problem in precisions. Can you realize measurement technique, which can be correct or never be correct....!!

Here is Quest for the "Mystic" Software which has zero bug...We will love it, but is it the shortcoming of the measurement or the human intellect. Share your view ?

Question is what we are measuring, if it is the human intellect or the precession of the human mind.

Be part of the inquest which can measure the fuzzy variable of human mind ...