Aug 3 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
Software Project,
project management standard,
software project management
1. Evolve, develop and freeze standards.
2. Keep a breathing space by not developing too rigid standards.
3. Live with open mind. Always be open for change in standards, if it is for improvement, and if it makes sense.
4. Let everyone involved in the projects have the same drink at the cocktail. Distribute the standards to all. Make it available on demand.
5. Understand the usefulness of standards. Don’t follow them just for the sake of it.
6. Let it not be too bulky in terms of documentation work involved in following standards. Standards should not supersede projects and hamper their progress.
7. Let everyone use a common terminology defined in the standards so that everyone speaks same language. Not that everyone using their own project terminology.
8. Standardize but don’t compromise.
9. Goal of standards should be achieving success in projects in a better way.
10. Follow standards.
Jun 17 2009 10:00AM GMT
Posted by: Jaideep
User Manual,
Software Project,
software project management,
key user,
stakeholder,
project implementation,
post implementation,
user feedback,
usability,
reliability,
stability,
durability,
report,
analytic,
feel and look,
product support,
project support,
live run,
product training,
software training,
training team,
implementation team,
project team,
project sign-off,
sign-off,
business scenario
The product owners or stakeholders might be many in a software project, but the real frontrunners who drive, run and use the software product post implementation are the key users and other users. It is their feedback that matters most. They must be the most comfortable lot on usability, functionality, reliability, stability, durability, resultant outputs in terms of reports and analytics, feel and look of the product. They are the one who are going to matter most in the success or failure of a product during and post implementation. The best tool to give them comfort, satisfaction, confidence and support is the User Manuals that they refer to most of the time during post implementation live run.
Even if the product is excellent and trainings are most rigorous ones, in absence of the project implementation team, every now and then the key users will be seeking help from User Manuals. User Manuals are the supporting agents for them at all times. That is why User Manuals have to be perfect in all aspects.
Infact a user manual prepared for product users should be such treated as a replacement of implementation and training team right from the moment the project is signed off and users start using the product in real business scenario.
Jun 1 2009 9:00AM GMT
Posted by: Jaideep
post implementation review,
software business,
Software Project,
software project management,
software implementation,
project effectiveness,
product usefulness,
product maturity,
product friendliness,
risk perception,
Risk Management,
key user management,
product acceptance,
project requirements,
product development,
product building,
team management,
project implementation process
What is post implementation review? When it should be done? Why is it required? All this has been discussed in last three posts. Let us now understand what ideally would be the components of a post implementation review. As discussed earlier, some components can be answered immediately at the completion of a project with a formal closure. But for answering some other components, customer needs some time for project to run in the absence of project team, experience it, feel it, see the user’s reaction on the way things are happening in the product when it is in use.
Infact before filling the post implementation review, it is advisable to use the software at its maxima, as extensively as possible, involving all key user’s areas, using all inflow and outflow procedures. The basic guidelines required while filling a post implementation review can be take up in my next post. Let us also understand that this questionnaire has to be quite elaborative and descriptive. Let us first understand the essential components of Post Implementation Review for a software project. The questions can be built as per the need of the vendor and product. The essential components to be covered are:
1. Effectiveness of the Project Team
2. Effectiveness of Customer management in managing Product understanding and implementation
3. Effectiveness of Customer management in understanding the requirements, building the product, selecting the right team and procedure
4. Change management during the complete cycle
5. Issues management
6. Preparedness of key users and management for accepting the product
7. Communication skills and management of vendor team and management
8. Risk perception, risk management
9. Product effectiveness, usefulness, maturity and friendliness
10. Customer management eagerness for future business to the same vendor
These are the core components based on which the elaborative questionnaire can be build to assess customer satisfaction over the product, vendor and team.
Apr 6 2009 10:29AM GMT
Posted by: Jaideep
SDLC,
software project management,
Risk lifecycle,
Risk Management,
risk identification,
risk assessment,
risk impact,
impact analysis,
countermeasure,
fool-proofing,
risk severity,
Project Lifecycle,
Software application
Similar to SDLC (software development lifecycle management), there is RLC or Risk lifecycle management in a software application in which there are different stages involved. The different stages could be risk identification, risk assessment, impact analysis, countermeasure identification, countermeasure assessment, risk plan etc. There are certain facts about Risk:
1. All Risks identified or perceived in a software application do not necessarily happen in real application usage scenario: This is a proven fact that all risks identified or perceived from an application during its pre-launch stage do not happen during post launch real-life usage stage. Some risks perceived may not happen ever. And some unidentified risks may appear later. Whatever is the case, it is always good to identify the risks that may occur during its usage, the more realistic the better. It is not important that they happen in real scenario, more important is to plan how to cope up if at all they happen.
2. All risks have an impact: All risks have an impact – large, medium or small, but they have. It is the impact that makes its severity high, medium or low and accordingly a plan is prepared to handle the risk, when it happens.
3. Same risk in different circumstances will have different impact: The same risk will vary in terms of its severity under different circumstances of usage, user base, geographic location, type of application etc.
4. No application is 100% risk free, whatsoever countermeasures are taken for it, and only thing that gets done with the countermeasures is lowering of risk: A risk plan to countermeasure a risk never fool-proofs a risk’s impact, only it helps in lowering its impact to a certain level.
5. Risk Impact Cost vs. Countermeasure cost: It is very important to have an analysis of both before deciding on the plan. Some risk may be very severe but its countermeasure cost could be unaffordable.
6. The biggest risk in any application is identification of wrong risks, impact, and plan: Identification of wrong risk with right estimation of impact and countermeasure is useless. Equally useless is identification of right risk with wrong impact analysis (thereby underestimating or overestimating the impact) and arriving at a wrong countermeasure. Right risk identification with right impact analysis but with wrong countermeasure also is a waste of efforts.
Feb 25 2009 10:02AM GMT
Posted by: Jaideep
Software Project,
software business,
software project management,
project objectives,
business survival,
growth,
revenues,
profits,
maturity,
Project Lifecycle,
standards and methodology,
software metrics,
stakeholders,
transparency,
project completion,
project sign-off,
customer satisfaction,
customer delight,
customer requirements,
software requirements,
Team building,
team role,
team responsibility,
team accountability,
software quality,
project quality,
first time right,
project overrun,
continuous learning,
Increase in revenue,
Avoid revenue loss,
Reduce costs,
Avoid cost increases,
Improved service
Certainly and obviously, every business has a set of objectives. Every business strives for survival, growth, revenues, profits, satisfaction and maturity. The clearer the objective are, the easier it is to achieve them. To achieve the objectives, if the destination is clear, it becomes easier to set the direction of the business, to set the milestones, to chalk out the roadmap, to set the drive, to decide the pace and to achieve them. The top 20 end objectives of any software project can be listed as below (note that the hierarchy is not as critical as the understanding of the gravity of each of the objective):
1. Control on Project Lifecycle
2. Standards and Methodology
3. Metrics
4. Stakeholders rights
5. Transparency
6. Pro-active approach to avoid post-mortem
7. Universal approach for similar projects
8. Timely completion, sign-offs and payments
9. Customer satisfaction and delight
10. Customer requirements and both end clarity on objectives of the product
11. Team building
12. Roles, responsibilities and accountability
13. Continuous Learning from failures/ overruns – no repetition of same mistakes to achieve continuous improvement overall
14. First time right approach
15. Quality right from start – ongoing – every step
16. Increase in revenue
17. Avoid revenue loss
18. Reduce costs
19. Avoid cost increases
20. Improved service
Feb 23 2009 10:43AM GMT
Posted by: Jaideep
Software Project Lifecycle,
pain areas of a software project,
Software Project,
customer requirements,
software project management,
software metrics,
Methodology and Standards,
documentation,
Customer requirements understanding,
Measurement of Overrun,
Project Status review,
Role clarity,
Risk analysis,
Team building,
Project Repository,
Learning from Past,
Post implementation support,
Quality – man,
methods,
approach and deliverables,
Version Control
Following are the top 15 pain areas of a software project. All points listed below appear somewhere or the other in a software project lifecycle. The ratio of pain from a particular below listed item may vary from project to project within an organization, and also from organization to organization. So although the hierarchy may vary, the pain areas somehow remain the same. A lack in addressing any one of the issue listed below may call for a big hiccup in the smooth running and closure of a project. The project size (and in turn the time and team size also) will vary depending on customer and customer requirements. Although all points listed below are self explanatory, but the understanding and perception may vary from individual to individual.
In that respect, I would like to take each of the points below one by one in my forthcoming blogs to explain how much impact each of the instrument listed below will have on the project and how to overcome this pain not only for that projects but for all the projects in that organization to come in future. The most important activity for each individual is, now, to re-arrange the points (with any additions/ or replacements) according to the ratio of pain it is giving, and then learn how to convert that pain into pleasure once for all (in my future blogs for the later part!)
1. Methodology and Standards
2. Documentation
3. Customer requirements understanding
4. Measurement of Overrun is in money terms immaterial of time overrun (time is not measured in terms of money)
5. Frequent Status review in a forum
6. Status of project movement is person based
7. Role clarity to project manager and team on site
8. Risk analysis
9. Team building
10. Customer clarity in terms of milestones and payments
11. Project Repository
12. Learning from Past
13. Post implementation support
14. Quality – man, methods, approach and deliverables
15. Version Control
