Oct 9 2009 6:29AM GMT
Posted by: Jaideep
Project Lifecycle,
Software Project,
project team,
project phase,
tester,
developer,
software development,
software testing,
implementation,
software product
Phase I: There is nothing called ‘off the shelf” product. It is all ‘made-to-fit’ technique. You specify your requirements and that too at a broader level. For micro level leave a red-mark at areas that need to be looked into at the time of building of software. The more red-marks will mean less precise plan and deadlines. The sooner we are able to convert these red-marks (not clearly known ones) to the clearly defied requirements, the better plan we can submit.
Phase II: The requirements will go to a team of developers who will build the outline or prototype of what is required by the customer, will get is approved from them and then will build the business requirements in it. Once they are through with it, the product will go to phase III.
Phase III: The product is handed over to a team of testers. These testers are technically stronger than the team that built the product. So this team will take the total ownership of the product from the team responsible for phase II. This team will find out the bugs, remove the bugs, fine tune the bugs and will hand over the final product to the implementation team.
Phase IV: The implementation team will interact with phase III team for any shortfalls in the product. Any new requirements will go to phase II team. Post implementation support also will be with the same team.
Aug 12 2009 10:00AM GMT
Posted by: Jaideep
Project,
Software Project,
Project Lifecycle,
project phase,
project execution
What is cycle time?
Cycle time in terms of a software project is the time taken from its initiation to handover. Another measure in terms of commercials could be order to execution to recovery… A project lifecycle in other terms
Do you measure it?
You might be banking on your experience without any data in place!
What is your definition of project cycle time?
In your opinion it might be what I said above. It might be nothing for you! Or might be some other definition!!
Is it merely based on gut feeling and past experience?
If you are not recording the development of a project from one stage to another, your cycle time measurement sheet could be a blank sheet.
What is objective measurement?
As we all know each project has several phases. Each phase is divided in milestones. One measure could be the time taken by each milestone from it planning to completion. There would be certain parallel activities. On the other hand some activities could be incremental in nature. Measure accordingly.
Do you segregate your similar type of projects?
You might be running different types of projects. Some could be similar to each other and may fall in one category. Another set of projects could make another category.
Do you know average game is successful for similar types?
An average cycle time worked out for similar set of projects falling in one category will work best for you for your future estimations and meeting those estimations. Else average may not work well and estimations may go haywired.
Jul 13 2009 10:00AM GMT
Posted by: Jaideep
performance testing,
software testing,
testing,
quality control,
bottleneck,
execution,
Project Lifecycle,
Software Project,
testing lifecycle,
testing phase,
testing tool,
testing parameter,
testing component,
load testing,
volume testing,
stress testing,
Test Plan,
test strategy,
load modeling,
scripting,
test script,
testing script,
benchmarking,
test case,
test execution,
test report,
testing report
As in a software project, the complete project lifecycle comprises of different phases. Similarly the performance testing lifecycle also comprises of various phases. Performance testing is usually, as the name suggests, is done to evaluate or examine the performance of the software product with the help of some tools and certain parameters. The performance testing may include components based on the requirements that include – load, volume, stress etc.
Five prominent phases of performance testing can be:
Phase 1:
a) Test Plan
b) Test strategy
Phase 2:
a) Load Modeling
b) Scripting
c) Benchmarking criteria
Phase 3:
a) Benchmark execution
b) Other executions
c) Reports generation
d) Reports Analysis
Phase 4:
a) Reports reconciliation
b) Reports compilation
c) Final Test Report
d) Bottlenecks identification
e) Recommendations
Phase 5:
a) Execution of recommendations
May 13 2009 9:35AM GMT
Posted by: Jaideep
Project Management,
project stakeholders,
project sign-off,
Project Lifecycle,
project milestones,
project achievements,
project stages,
Software Project,
project manager,
project vendor,
project customer
Sign-off at various stages has a significant importance during project lifecycle. Everyday sign-off can be a headache for customer, no sign-off can cause headache for vendor, so there has to be a balance of sign-offs of milestones, achievements and stages of project so that the sanctity of sign-offs is retained thereby earmarking the progress of project. Both, vendor and customer have to be very careful in this aspect of project management as it is crucial for all stakeholders.
At Vendor side the Project Manager has to educate the customer management and project manager over the benefits of timely sign offs. Sign-off should not be there just for the sake of it. It should add substantial value to the project.
At Customer end the Project Manager and management should respect the timely sign-off practice but also ensuring that the activity which is being signed off has finished in actual, rightfully and rightly.
May 8 2009 10:09AM GMT
Posted by: Jaideep
change management,
Project Management,
Software Project,
Risk Plan,
Risk Management,
risk mitigation,
manpower management,
Project Lifecycle,
project stages,
project guidelines
Although it can not be avoided in real life scenario and that is why there is a risk plan and risk management to avoid such circumstances. But still a lot can be done to atleast minimize the risk and thereby mitigation.
Vendor - Management has to ensure the bare minimum changes (preferably NO CHANGES) in terms of project manager and team members during the project lifecycle.
They also have to ensure that the project is handled in such a manner that any change(s) happening therein will not affect or delay any of the stage.
Customer - Management has to ensure the bare minimum changes (preferably NO CHANGES) in terms of project manager and key users during the project lifecycle.
They also have to ensure to adhere to the guidelines specified by vendor project manager to manage such change(s) so that it does not affect or delay the project during any stage of the project.
Apr 13 2009 10:01AM GMT
Posted by: Jaideep
project manager,
Software Project,
project implementation,
Project Management,
Project Lifecycle,
software development,
software testing,
software implementation
No project manager can claim there was not a single problem in any of his projects. But then he is to tackle them. To tackle them he should be aware of them. To be aware of them, he has to have an ability to foresee them than to overlook them. The earlier he envisages those problems, the more time he will get to dig into and find out a countermeasure. No software project is problem free, but then… the project manager has to be alert and have a perfect vision to oversee them, accept them, plan accordingly and win over each of the issues.
Problems will definitely be there, in all phases of project lifecycle. It is the vision that you envisage them in advance and prepare yourself to overcome them.
The deficiencies do not get so highlighted during in-house development and testing phase of the product. But it becomes prominent any problem that arises at customer site during the implementation phase, or say post implementation period.
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.
Mar 11 2009 10:15AM GMT
Posted by: Jaideep
1. Software Supplier Organization,
Software Project Ownership,
Software Project,
software development,
Project Lifecycle,
project monitoring,
project manager,
Project Initiation phase,
roles and responsibilities
Ownership is a big issue in a software project. Customer organization assumes that since they are spending money, it is the sole responsibility of supplying organization to make the project a success. Vendor organization on the other hand assumes otherwise. Who is right? I think both are wrong at their ends. A Project can never become a success while the two agencies involved act as separate islands. Both have to take the equal ownership to make it a success.
The six important mandates that a vendor organization should follow in that regards can be listed as below:
1. Involvement of top management is mandatory: Involvement of top management of the organization engaged in development of software product for an external customer has to be involved in the complete project lifecycle to make it a success. This does not mean a day-to-day involvement in monitoring the progress but there should be some metrics to monitor the overall progress at any moment of time. Another aspect is involvement of top management gives a serious impact on the progress of the project.
2. A dedicated project manager should be nominated for the complete project lifecycle: Right at the Project Initiation phase, a dedicated project manager needs to be assigned for the project. The selection of project manager should be very carefully done, keeping in mind that not only he should be expert in managing a project but he should have ample business knowledge also related to the project he is being assigned to manage.
3. Role of project manager and team has to be well defined at the start of a project: The roles and responsibilities are important to be defined well in advance to clear any ambiguities and to smoothen the progress path.
4. The project manager will act as a consultant to the customer regarding project plan and its adherence: It is the sole responsibility of customer project manager (and in turn their top management) regarding availability of customer project manager and key users in various stages of the project as agreed upon. Project Manager and the supplying organization have to act as a consultant. The responsibility to gear up the progress falls on the customer team. Vendor team can help them in support and educate them on how to achieve it.
5. The management has to ensure that the project manager and the team chosen for the customization/ development have to have enough business knowledge (of their respective domain) apart from technical skills: As mentioned above regarding the project manager, the same holds truth for developers, and testers too. Without reasonable business knowledge, even the expert developers and testers will not able to do the full justification to the product being built/ developed.
6. Project Manager has to ensure during the project lifecycle that the person who is signing off the requirements, UAT, and other stages from customer end is authorized person from customer management to do so: Many a times it happens that in a very busy scenario or with some other top priorities in hand, the customer management instead of releasing appropriate person for the relevant job, ask some junior person to do so which creates lot of issues.
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
