Tuesday, December 13, 2005
Business Case Preparation - Part 1 of 2 (Principles)
Often, within each SDLC, there are various decisions that need to be made. For example, should we buy or make the middleware for a project? Is it more effective to repair or replace a highly defective module? What are the options available, and what is the cost and benefits associated with each? Using business case tradeoffs to study each option, we can decide based on quantitative and qualitative factors involving both technical and business considerations. The following principles can serve as a guide in the preparation of a business case:
Decisions are made relative to alternate options - there may not be an ideal solution. Each option has its pros-and-cons. A choice is made relative to the pro-and-cons of other options, the technical and business constraints of the project.
Use money as a common deminator - Apply this where possible; highlighting the prospective consequences of each option using common monetary units. This should also be presented using Net Present Value (NPV) to take into account time value of money. This allows a common base on which to compare options against; and it is a familiar comparison means to business decision makers.
Sunk Costs are Irrelevant - Sunk costs are funds already committed. They have no impact on future actions and should not be taken into consideration.
Investment decisions should factor time value of money - Money's value decrease over time, due to inflation; or increase over time, due interests from bank. Money left in bank can earn interests of x% (minimum rate of return). Therefore, any investment option should yield more than x% to be worth consideration. Bearing this in mind, future projected returns must be presented using net present value (NPV) for a complete comparison. Example assuming interest rate of 8%
Decisions are made relative to alternate options - there may not be an ideal solution. Each option has its pros-and-cons. A choice is made relative to the pro-and-cons of other options, the technical and business constraints of the project.
Use money as a common deminator - Apply this where possible; highlighting the prospective consequences of each option using common monetary units. This should also be presented using Net Present Value (NPV) to take into account time value of money. This allows a common base on which to compare options against; and it is a familiar comparison means to business decision makers.
Sunk Costs are Irrelevant - Sunk costs are funds already committed. They have no impact on future actions and should not be taken into consideration.
Investment decisions should factor time value of money - Money's value decrease over time, due to inflation; or increase over time, due interests from bank. Money left in bank can earn interests of x% (minimum rate of return). Therefore, any investment option should yield more than x% to be worth consideration. Bearing this in mind, future projected returns must be presented using net present value (NPV) for a complete comparison. Example assuming interest rate of 8%
- Project A returns $50K annually over 4 years.
- Project B returns $25K annually over 8 years.
At surface, it seems both projects return $200K (50K x 4 or 25K x 8) eventually. However, Project A has a higher NPV of $178.9K compared to Project B's NPV of only $154.9K. So Project A is a better investment choice than Project B. This principle only applies for large sums occuring over long period.
Separable decisions should be considered separately - The decision of whether to invest in unit trust should not be mixed with the decision on which unit trust to invest in. They are 2 different decisions that should be considered separately.
Decision should consider both quantitative and qualitative factors - Whenever possible, options should be weighted quantitatively. However, this is not always possible. For example, morale of team members, customer satisfaction are hard to quantify accurately. This does not mean that these factors should be omitted in business case tradeoffs.
Risk associated with a decision should be quantified if possible - A decision made will have its associated risks. What if the option selected did not work out? What are the mitigation and contingencies measures? What are the related costs of these measures? These should be quantified and factored into the overall tradeoffs.
Timing associated with the decisions is critical - If relevant, take into account issues of budgetary cycle. Some companies have budget cycles that if missed, will mean another year of waiting before you can request for new budget.
- Adapted from 'Making the Software Business Case - Improvements by the Numbers', Donald J. Reifer
Separable decisions should be considered separately - The decision of whether to invest in unit trust should not be mixed with the decision on which unit trust to invest in. They are 2 different decisions that should be considered separately.
Decision should consider both quantitative and qualitative factors - Whenever possible, options should be weighted quantitatively. However, this is not always possible. For example, morale of team members, customer satisfaction are hard to quantify accurately. This does not mean that these factors should be omitted in business case tradeoffs.
Risk associated with a decision should be quantified if possible - A decision made will have its associated risks. What if the option selected did not work out? What are the mitigation and contingencies measures? What are the related costs of these measures? These should be quantified and factored into the overall tradeoffs.
Timing associated with the decisions is critical - If relevant, take into account issues of budgetary cycle. Some companies have budget cycles that if missed, will mean another year of waiting before you can request for new budget.
- Adapted from 'Making the Software Business Case - Improvements by the Numbers', Donald J. Reifer
Common Challenges and Principles Implementing organizational Changes
The following are some common challenges to change improvement and some guidelines that can be adopted to overcome them. How do they relate to project management? Well, I see them as relevant because project are often the means by which changes are brought about in an organization (as opposed to operations). I observed these challenges are common within projects that I have worked on. It is largely related to the project environment, not directly linked to project deliverables, and hence often overlooked. However, if not taken into considerations and managed properly, the PM will have difficulties in dealings with stakeholders and can affect the success of the project.
COMMON CHALLENGES OF ORGANIZATIONAL CHANGES
Lack of Incentives - Sometimes automation/process re-engineering can cause jobs to shrink, become cheaper and more manageable. But it can also reduce the perceived importance of that job, and there is little incentive for the affected incumbents as stakeholders to support the project. Where possible, reward system must be changed to show that management is 100 percent behind the initiative. PMs should perform stakeholder impact analysis and include negative stakeholders who may have strong influence on the outcome of the project.
PMs' Performance Evaluation Not Aligned to organization Goals - Most often, project managers are evaluated based on their abilities to complete a project on schedule and within budget. Doing something on a project for the good of the organization may be counter to these primary objectives. Improvement initiatives that can interfere with being on schedule and within budget may be perceived as project risks and are avoided. Where possible, the performance evaluation and rewards system must be changed to reflect the organization's goals.
Few Meaningful Metrics - Most companies don't collect data needed to quantify and measure project performances as part of their standard processes. These are often viewed as overhead that does not contribute to the delivery of the project goals. However, without these metrics, how do we measure the improvements that can be brought about by changes?
Lack of Resource - Money/time/manpower is never enough for the tasks list. However, without improvement via changes, resources are not freed up; and without freed resources, improvements will not happen. The recommended approach is to seek incremental changes, and use the small improvement to justify subsequent change improvements initiatives.
Seek Management Sponsorship - All major changes need senior management sponsorship to ensure that resources required are allocated and to set the aim/goals of the change. Not to forget the any project has a budget, and management sponsorship will help a lot in winning budgetary battles. To achieve this, the aim of improvements must be aligned with that of the management. It will not help if the management are looking to reduce cost, when you are proposing for increased quality.
Stakeholders must be Convinced of the Benefits - Everyone impacted by the changes must be convinced that the change is for the better and makes sense. Support at all levels must be developed by the PM. Otherwise, those who fear changes will resist it, especially if they don't understand that the change will help them do their job better.
Measure Improvements - All change initiated aims for improvements in one or more of these areas:
COMMON CHALLENGES OF ORGANIZATIONAL CHANGES
Lack of Incentives - Sometimes automation/process re-engineering can cause jobs to shrink, become cheaper and more manageable. But it can also reduce the perceived importance of that job, and there is little incentive for the affected incumbents as stakeholders to support the project. Where possible, reward system must be changed to show that management is 100 percent behind the initiative. PMs should perform stakeholder impact analysis and include negative stakeholders who may have strong influence on the outcome of the project.
PMs' Performance Evaluation Not Aligned to organization Goals - Most often, project managers are evaluated based on their abilities to complete a project on schedule and within budget. Doing something on a project for the good of the organization may be counter to these primary objectives. Improvement initiatives that can interfere with being on schedule and within budget may be perceived as project risks and are avoided. Where possible, the performance evaluation and rewards system must be changed to reflect the organization's goals.
Few Meaningful Metrics - Most companies don't collect data needed to quantify and measure project performances as part of their standard processes. These are often viewed as overhead that does not contribute to the delivery of the project goals. However, without these metrics, how do we measure the improvements that can be brought about by changes?
Lack of Resource - Money/time/manpower is never enough for the tasks list. However, without improvement via changes, resources are not freed up; and without freed resources, improvements will not happen. The recommended approach is to seek incremental changes, and use the small improvement to justify subsequent change improvements initiatives.
PRINCIPLES OF IMPLEMENTING PROCESS CHANGE
Seek Management Sponsorship - All major changes need senior management sponsorship to ensure that resources required are allocated and to set the aim/goals of the change. Not to forget the any project has a budget, and management sponsorship will help a lot in winning budgetary battles. To achieve this, the aim of improvements must be aligned with that of the management. It will not help if the management are looking to reduce cost, when you are proposing for increased quality.
Stakeholders must be Convinced of the Benefits - Everyone impacted by the changes must be convinced that the change is for the better and makes sense. Support at all levels must be developed by the PM. Otherwise, those who fear changes will resist it, especially if they don't understand that the change will help them do their job better.
Measure Improvements - All change initiated aims for improvements in one or more of these areas:
- Reduce Time to Market
- Reduce Cost
- Increase Quality
- Increase Productivity
To have continuous support from stakeholders, quantifiable measures is the best way to tell the story. It requires that a baseline on the current situation against which a comparison with the improvements can be made. Once these metrics are collected, the numbers will do the talking and serves to convince stakeholders of the benefits.
Continually Sell Your Business Case - Improvement must be sold continually; otherwise, the support base may be lost. Again, this requires metrics to be continually collected to monitor the benefits, and ensure ongoing support.
Continually Sell Your Business Case - Improvement must be sold continually; otherwise, the support base may be lost. Again, this requires metrics to be continually collected to monitor the benefits, and ensure ongoing support.
Thursday, December 01, 2005
What is Architecture-centric Software Project Management?
Problem
One common scenario is that cost and schedule estimates of software projects are required for justifying the business feasiblity of a software project, at a very early stage in the project life cycle. The difficulty is that there is little knowledge of requirements and the final product then to derive at feasible estimates. Hence, these estimates are usually inaccurate based on "expert judgement" or ballpark guesses.
One common scenario is that cost and schedule estimates of software projects are required for justifying the business feasiblity of a software project, at a very early stage in the project life cycle. The difficulty is that there is little knowledge of requirements and the final product then to derive at feasible estimates. Hence, these estimates are usually inaccurate based on "expert judgement" or ballpark guesses.
Solution
Using architecture-centric software project planning (ACSPP), it provides some guidelines on arriving at more realistic estimates. Figure 1 below shows where ACSPP fits into the software development life cycle. Notice that functional and system requirements specification are performed first, which is required to derive the high-level design by the system architects. The high-level architecture then serves as input to ACSPP, and acts as the basis for project planning.
Using architecture-centric software project planning (ACSPP), it provides some guidelines on arriving at more realistic estimates. Figure 1 below shows where ACSPP fits into the software development life cycle. Notice that functional and system requirements specification are performed first, which is required to derive the high-level design by the system architects. The high-level architecture then serves as input to ACSPP, and acts as the basis for project planning.
Figure 1 - Software Development PhasesThe ACSPP approach is summarised in Figure 2 below; High-level architecture is being produced by the architects as the project manager is concurrenlty working on the top-down schedule estimates. The top-down schedule can be derived from the subsystems identified from the high-level design. This approach requires the project manager and the architects to work closely together to derive an architecture and schedule estimate that is both technically feasible and meets business needs. The outputs from these two activities serves as key inputs into later activities, which are discussed next.
Figure 2 - Architecture-centered Software Project PlanningHigh-level Design - The aim here is to derive the subsystems/modules and scope of work that is to be done, which serves as basis for project planning. Top-level design decision are done here to serve as basis for planning as well; examples are development languages and deployment platforms etc. It also aims to resolve primary technical feasibility issues up front in the project life cycle where a "go-no-go" decision can be made if it is not technically feasible. Proof-of-concepts can be performed here to determine technical feasibilities, based on the perceived level of technical risk involved.
Top-down Schedule - Concurrently, the project manager derives the top-down schedule based on the subsystems identified from the high-level architecture. Parametric estimation techniques like COCOMO and Function-point analysis can be used here. Additional inputs can be from historical data of similar projects. Estimates at this point are still sketchy and accuracy is subjected to availability of accurate historical data. However, these activities do provide useful outputs, in that they help the project manager not to forget any significant considerations when planning the project. Examples includes SCM related tasks, project management life cycle tasks, and considerations like experiences of developers and if there are precedent project of similiar nature.
Bottom-up Estimates - Once the high-level architecture is completed, a bottom-up estimate can be derived using the subsystems and modules identified from system breakdown analysis. The granularity of the breakdown will depend on various factors like time, precedentness of similiar systems, and technical risk involved. Outputs from top-down scheduling are included at this point; the work breakdown structure includes primary activities to produce the software product AND any supporting activities necessary for the production, examples like project management tasks, meetings, reviews, SCM tasks, end-user training, documentation etc.
Release Plans - Suitable for incremental life-cycles; release planning identifies, prioritises and communicates what feature sets are available in which release and by when. The release plan helps to communicate with marketing department and distribution/deployment staffs on the major milestones to watch out for. It also allows the project managers to plan for resources required at certain phases of the life cycle e.g. arranging for beta testers prior to full release. Features' release are prioritised, using the high-level architecture, top-down scheduling and any business constraints (e.g. date of trade shows, need to operationalised new system by certain date). This serves as inputs for later scheduling efforts so that the project schedule meets business's needs.
Project Schedule - Using the top-down schedule, bottom-up estimates and release plans as inputs, a preliminary project schedule can be worked out detailing which activities is to be performed by who, and by when. Other consideration like public holidays and availability of resources (developers, testers, testing platforms etc) are factored here for a complete schedule.
Software Development Plan - The SDP details the entire plan required to produce the desired software product. The project schedule is included in the SDP to detail the time, and cost elements of this planning process.
Conclusion
Bottom-up Estimates - Once the high-level architecture is completed, a bottom-up estimate can be derived using the subsystems and modules identified from system breakdown analysis. The granularity of the breakdown will depend on various factors like time, precedentness of similiar systems, and technical risk involved. Outputs from top-down scheduling are included at this point; the work breakdown structure includes primary activities to produce the software product AND any supporting activities necessary for the production, examples like project management tasks, meetings, reviews, SCM tasks, end-user training, documentation etc.
Release Plans - Suitable for incremental life-cycles; release planning identifies, prioritises and communicates what feature sets are available in which release and by when. The release plan helps to communicate with marketing department and distribution/deployment staffs on the major milestones to watch out for. It also allows the project managers to plan for resources required at certain phases of the life cycle e.g. arranging for beta testers prior to full release. Features' release are prioritised, using the high-level architecture, top-down scheduling and any business constraints (e.g. date of trade shows, need to operationalised new system by certain date). This serves as inputs for later scheduling efforts so that the project schedule meets business's needs.
Project Schedule - Using the top-down schedule, bottom-up estimates and release plans as inputs, a preliminary project schedule can be worked out detailing which activities is to be performed by who, and by when. Other consideration like public holidays and availability of resources (developers, testers, testing platforms etc) are factored here for a complete schedule.
Software Development Plan - The SDP details the entire plan required to produce the desired software product. The project schedule is included in the SDP to detail the time, and cost elements of this planning process.
Conclusion
ACSPP guides the project planning process and ensures that key considerations of business needs and technical issues are factored into the plan. This ensures a more realistic plan based on known information at the early stages of the projecdt life cycle.
In addition, the outputs aids in communicating to stakeholders issues like what feature sets are available by which milestone, and if major business requirements in terms of time, cost and features are met.
However, it is noted the significant planning overhead required. At least preliminary requirements and high-level design must be performed before a certain accuracy in estimation can be achieved.
In addition, the outputs aids in communicating to stakeholders issues like what feature sets are available by which milestone, and if major business requirements in terms of time, cost and features are met.
However, it is noted the significant planning overhead required. At least preliminary requirements and high-level design must be performed before a certain accuracy in estimation can be achieved.
Tuesday, November 22, 2005
What is Software Architecture?
There have been some many interpretations and definitions of software architecture. I will attempt to document definitions that I have come across here for reference.
The Unified Modeling Language User Guide - "Architecture is a set of significant decisions about:
- The organisation of a software system.
- The selection of the structural elements and their interfaces by which they system is composed.
- Their behavior, as specified in the collaborations among those elements.
- The composition of these structural and behavioral elements into progressively larger subsystems.
- The architectural style that guides this organisation : the static and dynamic elements and their interfaces, their collaborations, and their composition."
Architecture-Centric Software Project Management - "Software architecture is concerned with capturing the structures of a system and the relationships among the elements ... The structures we found fell into several broad categories: conceptual architecture, module architecture, execution architecture, and code architecture."
Beyond Software Architecture - "A system architecture defines the basic 'structure' of the system (e.g. the high-level modules comprising the major functions of the system , the management and distribution of data, the kind and style of its user interface, what platform(s) will it run on, and so forth"
Beyond Software Architecture - "A system architecture defines the basic 'structure' of the system (e.g. the high-level modules comprising the major functions of the system , the management and distribution of data, the kind and style of its user interface, what platform(s) will it run on, and so forth"
Principles of Modeling
- The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.
- Every model may be expressed at different levels of precision.
- The best models are connected to reality.
- No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models.
Saturday, November 12, 2005
Mean and Standard Deviation Calculation
I was reading up on PERT (Program Evaluation Review Technique), one of the technqiues in estimating efforts in WBS (work breakdown structure). It appears that there is much more to estimation than just ball-park guesses.
I will share my lessons learnt on PERT later; however it appears the following are relevant lessons that needs to be learnt, as they are applied in PERT calculations.
I will share my lessons learnt on PERT later; however it appears the following are relevant lessons that needs to be learnt, as they are applied in PERT calculations.
Standard deviations is very important in PM estimations. One of the usage is in knowing the risk level of estimates. For example, I have the following sample of WBS:
Work Estimated Effort Std Deviations
Module A 20 man-days 1.0
Module B 20 man-days 2.0
What this means is that although both tasks are estimated to take 20 man-days to complete. Module B has a higher risk level as the higher deviation means that the actual effort is in the range of 20 man-days +/- 96%, as compared to Module A's 65%.
Work Estimated Effort Std Deviations
Module A 20 man-days 1.0
Module B 20 man-days 2.0
What this means is that although both tasks are estimated to take 20 man-days to complete. Module B has a higher risk level as the higher deviation means that the actual effort is in the range of 20 man-days +/- 96%, as compared to Module A's 65%.
Monday, November 07, 2005
ORCAS - Next Version of Visual Studio
Now that Whidbey is released, Microsoft is already starting prototyping of next version of Visual Studio, codenamed ORCAS.
Other than on tools, seems like there is strong emphasis on processes. There is the MSF template in include in the VS Team Systems (VSTS). I think we can expect more process templates to be included in the future.
"...offerings will likely not be "just about the tools," but also about the process and the approach enterprises might take to threat modeling and related issues."
Other than on tools, seems like there is strong emphasis on processes. There is the MSF template in include in the VS Team Systems (VSTS). I think we can expect more process templates to be included in the future.
"...offerings will likely not be "just about the tools," but also about the process and the approach enterprises might take to threat modeling and related issues."
SQL Server 2005 Takes On Enterprise Data Market
Finally, the much anticipated SQL Server 2005 is about to be released. Does this mean that Microsoft will take over Oracle and IBM in terms of enterprise level RDMBS? Already, there seems to be very good response, and one survey says that many are keen to migrate over.
If this does indeed happen, what this means is that there will be a sharp increase for demand of professionals trained in SQL Server 2005.
If this does indeed happen, what this means is that there will be a sharp increase for demand of professionals trained in SQL Server 2005.
Tuesday, November 01, 2005
Search Capabilities - The Next Thing to Look Out For
Google partners with IBM for corporate desktop search program. The cooperation aims to produce searching capabilities for unmanaged files like Word documents, images and managed data in corporate databases.
IT growth has created the problem of finding relevant information amidst the information overload. Now the search engines are becoming smarter and broader in terms of types of searchable items. This will definitely mean better information accessibility, and higher productivity.
IT growth has created the problem of finding relevant information amidst the information overload. Now the search engines are becoming smarter and broader in terms of types of searchable items. This will definitely mean better information accessibility, and higher productivity.
Tuesday, October 11, 2005
How TDD improves development speed and is very cost effective
Through Dr Neil's blog, I found this blog which is very relevant and good resource for agile development.
