Overview
Success of a masterpiece depends up on how it is architected. Any artifact and event need to be architected to take care of its fundamental and advanced need. Information Technology is more familiar with the word product architecture that project architecture. In some cases project architecture is used in case of product architecture considering that both is same.
We all know that Software product needs an architect but can we architect a Software project? Architecting a software product involves designing the product to be scalable, reliable and maintainable product. Who is responsible for cost effectively executing the project? Who will control the changes coming in the project? Who is responsible for overall execution?. Who will ensure that the client got the right product? How will we give value added idea to run the business of the client? Who will control the scope of the project?
This article defines a role for architecting a project that is the answer for all the above concerns.
Role of a project architect
One of the major reasons for the failure of a million dollar project is the lack of execution maturity. There are lots of maturity models/patterns available in the industry. CMM, CMMI, PCMM, RUP and Six Sigma are some of the industrially accepted standards. All of this standards defines the processes followed in the project, but does not hold with the dynamics of the projects, means the strategy of execution. Execution is different in different projects but it involves a common doctrine.
Every project except software project has defined a role called project architect. In software it is categorized separately as technical architect and that person will be only responsible for giving technical direction. Project manager will be overwhelmed by other responsibilities like Scheduling, Man management, Status Reporting and that role may not have bandwidth to think about execution.
Appropriate execution defines a need for defining a new role in the project called project architect. Project architect is the architect of project execution Project architect over sees the project in a detailed manner and understands nitty-gritty of the project and decided the course of action of the project. Project architect keeps a different perspective of project activities than a project manager. When project manager works on giving a workable environment for the team and track the schedule to identify any slippage, project architect work on taking the right decision or action in the project by closely analyzing the cost incurred in the project.
Project Architect should help project manager to understand what type of resources for what functionality is required. What is the grey area in the project? Which all areas we need commitment from customer. What is the root cause for an issue? Usually these areas are always handled by project manager along with other responsibilities and in turn giving a very secondary importance to the critical aspects of the project. By introducing project architect for this role, we are isolating and handling the most important and critical aspect of a project called project execution.
Responsibilities of a Project Architect
Project architect is responsible for the execution of the project. Project Architect should know each and every detail in the project. Below are the defined responsibilities of a project architect
• How to define which is cost effective path of execution?. It involved analyzing each and every activities and functionalities and identifies which is required path of execution.
• Project architect should have detailed business knowledge on all the modules so that responsible for identifying any dependency in the project.
• Conveys what is the technical problem in the project to technical team. Project Architect may not be the solution provider.
• Identify what is a change request and what is a requirement in the project.
• Identify business gaps in the project. Requirements can be captured to finest details but there can be still gaps in the understanding between the IT and the users. This gap has to be resolved during design phase. It is the responsibility of project architect to have the no gaps in the project after design phase.
• Analyze the cost/profit incurred in the project. Cost effective Execution also depends on the Cost /Profit Analysis of the project. For e.g. below graph provides idea of what is cost incurred in each week or phase.
Project manager can track cost and report the management when te cost is going above the expected limits. If a person has to architect the project in a cost effective manner for, he or she should know each and ever details of the project. If the project manager is spending time on that then the project will get executed in an uncontrolled manner. Considering project manager on this role is devastating.
Responsibilities of other roles in the Project
Account Manager:
Account Manager is responsible for stabilizing the account through effective client interaction Account Manager spends more time on the critical project with the project manager. He or She works above the hierarchy reporting the issues to the senior management.
Project Manager:
Project Manager is the owner of the project. Project Manager works with the support group for giving the environment for people to work and motivating the people. Project Manager is responsible for schedule tracking, procurement management, quality management, risk management, resource management etc.
Project Leader:
Responsible for making sure the project follows the right model. Responsible for deliverables of the project. Project Leader leads the team down the hierarchy working more with the team. Focus more on the critical path of the project. Project Leader is responsible for maintaining the quality of the product.
Technical Leader/Technical Architect:
Responsible for the design of the individual modules and owns the code devolved in the project. Technical Architect is responsible for taking the technical decision, creating a development habit among team members like good coding habits, enforcing the use of appropriate technology etc.
Architecting a Software Project.
Project Architect should know the requirements in detail, technical challenges, and dependencies with other departments before identifying the path of execution. With the mentioned details, project architect should be capable of judging the scope creep, critical path, most profitable path and resource utilization with in the project.
Project Architect need to be very diligent in watching the scope creep in the project. Scope Creep usually comes in the form of requirement changes. Change can come in any of the following ways.
1) Request not captured properly which creates a dilemma on whether it is change request or not.
2) Identifying the gaps in the project and removing it in the course of time. This is the toughest part of the project. Project architect can proactively take steps to reduce the gaps but removing it completely may not be possible.
3) Introducing new requirement to the project with out following proper Change Control Mechanism. Change requests are one of the profitable sources in a project. It need to be managed properly
Issue tracking through execution
We can only control the bugs/issues by proper execution but we cannot stop it completely. The important thing is to have a tracking mechanism. When an issue occur, the project manager increases the number of resources thinking that there is no efficient way to solve the problem other than increasing the hours. At that time there is no right person to identify the root cause of the problem. Project architect should own these issues in the project. Execution is not giving pat in the back of the people. Execution is not building a process and blindly following that. Execution is identifying the right process by properly analyzing the project and following it in a proper manner.
Reactive and Proactive approach for the project.
Project architect is a doer not a talker. Project architect is not only a problem solver but a person who avoids problem. By defining a role as project architect, we are introducing a person to be responsible for all the proactive and reactive aspects of the project. Project architect will own the executive decision of the project and identify way to tackle in the right way. Usually we define project leader as person to do things right and project manager to do right things. In a bigger perspective person who can do things right can only do right things. So defining a role called project architect, we are introducing a role just to do things right and right things in a project.
Monday, May 12, 2008
Software Project Failure
Most software projects fail completely or partial failures because a small number of projects meet all their requirements. These requirements can be the cost, schedule, quality, or requirements objectives. According to many studies, failure rate of software projects is between 50% - 80%. This essay is a compilation of failure causes of software development projects; this essay summarises several areas that play a vital role in software project failure.
So, what really is the reason for software project failure? The sad fact is that software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. We try to defend ourselves by saying that software construction is “different”.
One of the most serious complaints against software failure is the inability to estimate with acceptable accuracy the cost, resources, and schedule necessary for a software project. Conventional assessment methods have always produced positive results which contribute to the too well-known cost infested and schedule slippage.
Over the last 20 years many cost and schedule estimation techniques have been used with mixed sensation due to restrictions of the assessment models. A major part of the estimations failure can be due to a lack of understanding of the software development process and the effect of that method used in the project plan, schedule and cost estimates.
Failure Case Studies Below are few of the case studies considered which will be analysed to fetch the main reasons of failure of the software system.
Northumbria University developed accounting software to manage its day to day business. The project could not come up with the desired results and failed to meet the deadlines. Te investigations showed that the basic project management procedures were not followed. This case study is referenced in this essay at different points where necessary. [1]
Thai subsidiary (SMTL) of a Hong Kong-based multinational company (SMHK) engaged in the manufacturing of electronic equipment. They implemented an integrated software package; which was a failure at the several factors. These factors were mostly management related. Such as a poor fit between the business process assumptions inscribed in the software and the business processes in SMTL, poor leadership at different levels, cultural differences, organizational environment, and poor human resource management.
St John’s Hospital is a District General Hospital provides medical and nursing services, which includes both general surgery and medicine.All these services are supported by diagnostic imaging, laboratory, ambulance, pharmacy and therapy services, which are all on site. As the major hospital in a tourist area, it deals with many visitors in the holiday season, generating a large amount of non-booked admissions work.
Software Management & Leadership It has been shown repeatedly, that effective leadership is essential for successful IT implementation (Klenke, 1994). A leader must also have cultural sensitivity, communication skills, creativity, ability to delegate, and the ability to develop and retain human resources (Luthans, 1994). The software manager at (SMHK) was a western, where as the lower managers were Eastern. So there was a cultural clash going on always. Jack (Manager) always try to introduce creative thoughts. And most of the time the lower management could not do them. Hence there was a clash going on all the time.
Employees also felt that management hardly ever “listened” to their concerns or attempted to address them. Consequently, many employees were eager to leave the company, and did so as soon as they found alternate opportunities in other companies.
Project Planning & Scheduling Project planning means creating work breakdown, and then allocate responsibilities to the developers over time. Project planning consists of construction of various tasks, timelines and essential pathways including Gantt charts and PERT charts and different written plans for various situations.
It is quite usual in software development process to work backward from the project end date which results in complete software project failure. It is impossible that a project can be completed efficiently from the planning stage to the implementation stage.
Allocation of roles and responsibilities has to be clearly defined, and it becomes crucial while hiring the stall from outside. University’s higher management failed to apply the basic project management rules which laid to the project failure.
Proper scheduling is also required before the start of the project. It includes the time scheduling, teams scheduling. Project managers don’t know what they have to plan and schedule. They just only tell the programmer what to do and the programmers can come up with a proper solution.
The development was moved to a new office and the office was not fully equipped with the proper infrastructure. As time is also a big factor in success or failure of a project. So it delayed the development process and contributed towards the project failure. Infrastructure was not fully scheduled and management team didn’t know where and how the project development will be started.
The top secret of a winning software development project is to control the quality up and lower the risk. Contingency plan is also the part of planning. In case things went wrong then this plan can be followed to lower the affect of the failure of project. Same was the case with university’s accounting software. The management team had no such a contingency plan nor did they evaluate the risk involved in the development of the new system. So it caused more trouble without the backup system or backup plan.
The management just try to follow the methodologies like SDLC or RAD, but don’t know which methodology to use and at which time should apply the right technique.
Cost Estimation Cost estimation is mainly involved the cost of effort to produce the software project. But it’s not limited to the effort only. It also includes the hardware and software cost, training the employees and customer, travelling to the customer, networking and communication costs. Cost estimation should be done as a part of the software process model.
Cost estimation needs to be done well before the start of the project development. Failure of the budgeting for the cost of the project results in complete disaster. As stated above the infrastructure cost, development tools cost and hardware cost also needs to be estimated first.
Same thing happened to university’s accounting system development. They purchased the new system well with out any serious estimation of the cost and the income sources.
Below are the reasons why wrong cost estimation is done.
Inappropriate estimation methodology Another reason would be the use of an inappropriate cost estimation methodology. Not a single methodology is better than other. Every methodology has its own strong and weak points which should be considered. Dr. Barry Boehm’s book Software Engineering Economics lists seven estimation methodologies. One or more of these methodologies can be used to estimate the cost of a project
“Good suggestion is that more than one software cost estimation methodology should be used for accurate estimation”.
Cost estimation tools There are many drawbacks in manual cost estimation. This technique is almost obsolete now. These days successful cost estimation includes the use of appropriate commercial software cost estimating tool.
Good software estimating tools do not always guarantee reliable software estimates. Wrong input of the software size will result in wrong estimate. Estimation software also needs to be customised for the specific need of organization. These customisations require the data from the past projects as input for the tool to estimate.
There are number of reasons these tools can return the wrong estimate.
Choosing the right estimation tool
Choice of a right estimation tool is necessary for the right estimation. The tool is not capable of handling the input and thus it can come up with the wrong estimate and hence cause the software project to fail.
Ease of customisation
As mentioned above the selected tool must be customisable according to the organisation needs, so that the organization can customise it according to the needs and past project data.
Easy to use and learn
The cost estimation tool should be easy to use and learn. It must include help and examples, simple and straight forward user interface. It must require less training to learn the system and inputs should be well defined.
Accurate Estimation
The estimation tool must have the capability to analyse all the parameters and come up with the accurate estimation for the cost.
Risk Management Risk management is an important factor towards software project failure if it’s not managed timely and effectively. As nothing can be predicted that what will happen in future so we have to take the necessary steps in the present to take any uncertain situation in the future. Risk management means dealing with a concern before it becomes a crisis.
Risk Identification
According to the Universal risk Project there are two types of conditions which can be a symbol of as risk.
* IF-THEN Statements
o “IF technology is not available, THEN we will not meet the requirement”
o “IF we cannot hire sufficient qualified software engineers, THEN we cannot meet the planned development schedule
* CONDITION-CONSEQUENCE Statements
o Given the “condition”, there is a likelihood that the “consequence” will occur
o “Given that this specific test fails (the CONDITION), the CONSEQUENCE is that the planned schedule will slip”
Project managers have to identify the areas where the risk can be and how it can affect the development of the project. Risk can be of technical nature or non technical. Project managers needs to be aware of both the risks. Most of the projects managers are not good in either of the side. A good manager with programming skills can be good in identifying the technical risk but not in non technical risk.
Risk Analysis After the risk is identified there is a need to make the categories of that risk. Risk analysis is the process of examining the project results and deliverables after the risk analysis and applying the technique to lower the risk. After risk analysis is complete, the proper risk analysis plan needs to be made to cope with any uncertain situation. First identified risks are categorized and make the hierarchy of those risks. At this point the risk is classified as the positive or negative risks.
Risk Prioritization After the risk is analyzed, the next step is to priorities the risk. At first focus on the most sever risk first; and les sever later. These risk factors can worked from time to time so that the final project out come is free of risk. So most of the time project management team fails to identify the sever risk and work on the less sever risk. This often results in the form of a crisis.
Risk Avoidance Dealing with the risk is an art. Some times the management takes the projects with out identifying the proper risk involved in the project. So an experienced manager will take the project after proper risk analysis and avoid any risk involved in the project.
Risk control Managing the risk to achieve the desired results and deliverables is done through controlling the risk at its best. This is a pure intuitive process and depends on the experience of the project management team, or risk already managed in past projects which were done by the same organization.
Conclusion This essay has presented three basic factors which can cause the software development project to fail. Planning & Scheduling, cost estimation and risk management. All of these factors are to be considered at the management level and then transferred to the lower management.
Planning & Scheduling comes at first, good planning and scheduling makes the strong foundation for the software project. Project planning consists of construction of various tasks, timelines and essential pathways including Gantt charts and PERT charts and different written plans for various situations. If these factors are not taken into part then the software may encounter problems during the development and the final product will be a failure.
Cost estimation depends on the budget of the project, customer type and the size and effort to be put in the project. Cost estimations are done many times during the life cycle of a project. It affects the project in many ways, wrong estimation complete failure, affect the good-will of the organisation if the costs are not covered, stake holders are affected and waste of resources.
Managing the risk is a practical approach for decreasing the ambiguity and possible loss related with a software development project. Potential measures can be considered as opportunity-focused (positive risk) if their consequences are favourable, or as threat-focused (negative risk) if their consequences are unfavourable.
So, what really is the reason for software project failure? The sad fact is that software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. We try to defend ourselves by saying that software construction is “different”.
One of the most serious complaints against software failure is the inability to estimate with acceptable accuracy the cost, resources, and schedule necessary for a software project. Conventional assessment methods have always produced positive results which contribute to the too well-known cost infested and schedule slippage.
Over the last 20 years many cost and schedule estimation techniques have been used with mixed sensation due to restrictions of the assessment models. A major part of the estimations failure can be due to a lack of understanding of the software development process and the effect of that method used in the project plan, schedule and cost estimates.
Failure Case Studies Below are few of the case studies considered which will be analysed to fetch the main reasons of failure of the software system.
Northumbria University developed accounting software to manage its day to day business. The project could not come up with the desired results and failed to meet the deadlines. Te investigations showed that the basic project management procedures were not followed. This case study is referenced in this essay at different points where necessary. [1]
Thai subsidiary (SMTL) of a Hong Kong-based multinational company (SMHK) engaged in the manufacturing of electronic equipment. They implemented an integrated software package; which was a failure at the several factors. These factors were mostly management related. Such as a poor fit between the business process assumptions inscribed in the software and the business processes in SMTL, poor leadership at different levels, cultural differences, organizational environment, and poor human resource management.
St John’s Hospital is a District General Hospital provides medical and nursing services, which includes both general surgery and medicine.All these services are supported by diagnostic imaging, laboratory, ambulance, pharmacy and therapy services, which are all on site. As the major hospital in a tourist area, it deals with many visitors in the holiday season, generating a large amount of non-booked admissions work.
Software Management & Leadership It has been shown repeatedly, that effective leadership is essential for successful IT implementation (Klenke, 1994). A leader must also have cultural sensitivity, communication skills, creativity, ability to delegate, and the ability to develop and retain human resources (Luthans, 1994). The software manager at (SMHK) was a western, where as the lower managers were Eastern. So there was a cultural clash going on always. Jack (Manager) always try to introduce creative thoughts. And most of the time the lower management could not do them. Hence there was a clash going on all the time.
Employees also felt that management hardly ever “listened” to their concerns or attempted to address them. Consequently, many employees were eager to leave the company, and did so as soon as they found alternate opportunities in other companies.
Project Planning & Scheduling Project planning means creating work breakdown, and then allocate responsibilities to the developers over time. Project planning consists of construction of various tasks, timelines and essential pathways including Gantt charts and PERT charts and different written plans for various situations.
It is quite usual in software development process to work backward from the project end date which results in complete software project failure. It is impossible that a project can be completed efficiently from the planning stage to the implementation stage.
Allocation of roles and responsibilities has to be clearly defined, and it becomes crucial while hiring the stall from outside. University’s higher management failed to apply the basic project management rules which laid to the project failure.
Proper scheduling is also required before the start of the project. It includes the time scheduling, teams scheduling. Project managers don’t know what they have to plan and schedule. They just only tell the programmer what to do and the programmers can come up with a proper solution.
The development was moved to a new office and the office was not fully equipped with the proper infrastructure. As time is also a big factor in success or failure of a project. So it delayed the development process and contributed towards the project failure. Infrastructure was not fully scheduled and management team didn’t know where and how the project development will be started.
The top secret of a winning software development project is to control the quality up and lower the risk. Contingency plan is also the part of planning. In case things went wrong then this plan can be followed to lower the affect of the failure of project. Same was the case with university’s accounting software. The management team had no such a contingency plan nor did they evaluate the risk involved in the development of the new system. So it caused more trouble without the backup system or backup plan.
The management just try to follow the methodologies like SDLC or RAD, but don’t know which methodology to use and at which time should apply the right technique.
Cost Estimation Cost estimation is mainly involved the cost of effort to produce the software project. But it’s not limited to the effort only. It also includes the hardware and software cost, training the employees and customer, travelling to the customer, networking and communication costs. Cost estimation should be done as a part of the software process model.
Cost estimation needs to be done well before the start of the project development. Failure of the budgeting for the cost of the project results in complete disaster. As stated above the infrastructure cost, development tools cost and hardware cost also needs to be estimated first.
Same thing happened to university’s accounting system development. They purchased the new system well with out any serious estimation of the cost and the income sources.
Below are the reasons why wrong cost estimation is done.
Inappropriate estimation methodology Another reason would be the use of an inappropriate cost estimation methodology. Not a single methodology is better than other. Every methodology has its own strong and weak points which should be considered. Dr. Barry Boehm’s book Software Engineering Economics lists seven estimation methodologies. One or more of these methodologies can be used to estimate the cost of a project
“Good suggestion is that more than one software cost estimation methodology should be used for accurate estimation”.
Cost estimation tools There are many drawbacks in manual cost estimation. This technique is almost obsolete now. These days successful cost estimation includes the use of appropriate commercial software cost estimating tool.
Good software estimating tools do not always guarantee reliable software estimates. Wrong input of the software size will result in wrong estimate. Estimation software also needs to be customised for the specific need of organization. These customisations require the data from the past projects as input for the tool to estimate.
There are number of reasons these tools can return the wrong estimate.
Choosing the right estimation tool
Choice of a right estimation tool is necessary for the right estimation. The tool is not capable of handling the input and thus it can come up with the wrong estimate and hence cause the software project to fail.
Ease of customisation
As mentioned above the selected tool must be customisable according to the organisation needs, so that the organization can customise it according to the needs and past project data.
Easy to use and learn
The cost estimation tool should be easy to use and learn. It must include help and examples, simple and straight forward user interface. It must require less training to learn the system and inputs should be well defined.
Accurate Estimation
The estimation tool must have the capability to analyse all the parameters and come up with the accurate estimation for the cost.
Risk Management Risk management is an important factor towards software project failure if it’s not managed timely and effectively. As nothing can be predicted that what will happen in future so we have to take the necessary steps in the present to take any uncertain situation in the future. Risk management means dealing with a concern before it becomes a crisis.
Risk Identification
According to the Universal risk Project there are two types of conditions which can be a symbol of as risk.
* IF-THEN Statements
o “IF technology is not available, THEN we will not meet the requirement”
o “IF we cannot hire sufficient qualified software engineers, THEN we cannot meet the planned development schedule
* CONDITION-CONSEQUENCE Statements
o Given the “condition”, there is a likelihood that the “consequence” will occur
o “Given that this specific test fails (the CONDITION), the CONSEQUENCE is that the planned schedule will slip”
Project managers have to identify the areas where the risk can be and how it can affect the development of the project. Risk can be of technical nature or non technical. Project managers needs to be aware of both the risks. Most of the projects managers are not good in either of the side. A good manager with programming skills can be good in identifying the technical risk but not in non technical risk.
Risk Analysis After the risk is identified there is a need to make the categories of that risk. Risk analysis is the process of examining the project results and deliverables after the risk analysis and applying the technique to lower the risk. After risk analysis is complete, the proper risk analysis plan needs to be made to cope with any uncertain situation. First identified risks are categorized and make the hierarchy of those risks. At this point the risk is classified as the positive or negative risks.
Risk Prioritization After the risk is analyzed, the next step is to priorities the risk. At first focus on the most sever risk first; and les sever later. These risk factors can worked from time to time so that the final project out come is free of risk. So most of the time project management team fails to identify the sever risk and work on the less sever risk. This often results in the form of a crisis.
Risk Avoidance Dealing with the risk is an art. Some times the management takes the projects with out identifying the proper risk involved in the project. So an experienced manager will take the project after proper risk analysis and avoid any risk involved in the project.
Risk control Managing the risk to achieve the desired results and deliverables is done through controlling the risk at its best. This is a pure intuitive process and depends on the experience of the project management team, or risk already managed in past projects which were done by the same organization.
Conclusion This essay has presented three basic factors which can cause the software development project to fail. Planning & Scheduling, cost estimation and risk management. All of these factors are to be considered at the management level and then transferred to the lower management.
Planning & Scheduling comes at first, good planning and scheduling makes the strong foundation for the software project. Project planning consists of construction of various tasks, timelines and essential pathways including Gantt charts and PERT charts and different written plans for various situations. If these factors are not taken into part then the software may encounter problems during the development and the final product will be a failure.
Cost estimation depends on the budget of the project, customer type and the size and effort to be put in the project. Cost estimations are done many times during the life cycle of a project. It affects the project in many ways, wrong estimation complete failure, affect the good-will of the organisation if the costs are not covered, stake holders are affected and waste of resources.
Managing the risk is a practical approach for decreasing the ambiguity and possible loss related with a software development project. Potential measures can be considered as opportunity-focused (positive risk) if their consequences are favourable, or as threat-focused (negative risk) if their consequences are unfavourable.
Wednesday, March 26, 2008
Outsourcing Factors In Technical Projects for IT Industry
Nowadays, outsourcing seems to be a de facto approach in the IT industry. As a part of the software development process, it seems reasonable to consider technical writing as a candidate for outsourcing. Through this article, I propose to explore the pros, cons, risks, and opportunities for outsourcing your technical documentation.
1. Outsourcing: pros&cons
Let's start with the arguments in favor of documentation outsourcing:
1. The economic factor: outsourcing helps you decrease (or limit) your documentation headcount, your software licenses costs, and your general expenses (office space, PCs...).
2. The technical documentation process is standardized with a clear split of responsibilities, limited need for interactions, and well-known collaboration periods.
3. If technical documentation does not come high on the companies' strategy list, why not you let someone outside do it and focus on your core business?
4. The emergence of XML-based open documentation standards such as DocBook and DITA facilitate the split of tasks; moreover, this removes some of the lock-in effect big software vendors enjoyed; open source tools are available and reasonably priced.
The arguments against documentation outsourcing are the following:
1. The usual minuses: outsourcing adds a transaction cost that decreases the direct economical benefits; moreover, there is a learning curve for companies new to this process.
2. Usual software outsourcing relies on wages arbitrage opportunities; if you expect well written English documentation, then you need an English native speaker and the arbitrage opportunity greatly diminishes.
3. Partner selection: it is risky if your knowledge and experience in this field is limited (cost, technology, process); if you are looking at local providers, depending on your location, you may or may not have access to a big pool of providers.
4. On-site presence: some documentation (for example, printer manuals) require that your writers be on site from time to time to test the equipment.
5. There is a lack of collaboration tools to support distant teams and more importantly to organize efficient reviews. Hopefully, LiveTechDocs can help here!
Should you give it a try?
For big companies, it depends (I know that's an easy one):
* If you have divisions located where it is hard to find good tech writers, then you may consider it. HP Spain, for instance, decided to use an exclusive outsourcing partner to manage their printer documentation.
* Good option if you have high variability in workload.
* If the documentation is tightly integrated into your product or service and require frequent care, then avoid it. For instance, Salesforce uses the Agile development process with shorter release cycles.
SMBs, consider the following:
* If you have trouble accommodating with workload fluctuations and hiring an extra-employee does not make economic sense. The smaller the documentation team, the more relevant this is.
* If your documentation project is a "one-of" task why hire a full-time writer.
* If you lack the expertise in house, outsourcing is a viable option.
Outsourcing options
Who should you outsource to? Well, your options mainly depend on the size of the project and the type of relationship you want to develop:
* Big projects: go for the big guys (LionBridge, SDL...)
* Small to medium repetitive projects: select a business partner that can accommodate the sporadic workload; be aware of your negotiation power (i.e.: how important you are to this partner)
* Small to medium "one shot" project: consider single contractors or small boutiques
The next question is where to find your partner.
* Locally: this is usually easier to manage since the partner can be on site when needed; all it takes is an add on Craigslist!
* In the US: you may get arbitrage opportunities as costs for writers fluctuate between regions (ex.: Silicon Valley against the Mid West)
* Abroad: writers in Canada used to be affordable but a current weak-dollar is changing the rules of the game.
* On the Internet: it is a fast, easy, and cheap approach; check oDesk.com or Elance.com
Conclusion
There are a few compelling reasons to consider technical writing as a candidate for outsourcing: the process is simple enough, well understood, and documentation standards such as DITA and DocBook bring the flexibility needed to share and exchange documentation. However, there are also drawbacks: no previous outsourcing experience, inability to qualify providers, internal process or technologies that do not work well with outsourcing, and a lack of collaboration tools.
My belief is that in the future, documentation will be more open, fragmented, and integrated to the company product or service. Firms leading in their industry will use technology as a way to connect with users. As a result, outsourcing could be far less attractive.
1. Outsourcing: pros&cons
Let's start with the arguments in favor of documentation outsourcing:
1. The economic factor: outsourcing helps you decrease (or limit) your documentation headcount, your software licenses costs, and your general expenses (office space, PCs...).
2. The technical documentation process is standardized with a clear split of responsibilities, limited need for interactions, and well-known collaboration periods.
3. If technical documentation does not come high on the companies' strategy list, why not you let someone outside do it and focus on your core business?
4. The emergence of XML-based open documentation standards such as DocBook and DITA facilitate the split of tasks; moreover, this removes some of the lock-in effect big software vendors enjoyed; open source tools are available and reasonably priced.
The arguments against documentation outsourcing are the following:
1. The usual minuses: outsourcing adds a transaction cost that decreases the direct economical benefits; moreover, there is a learning curve for companies new to this process.
2. Usual software outsourcing relies on wages arbitrage opportunities; if you expect well written English documentation, then you need an English native speaker and the arbitrage opportunity greatly diminishes.
3. Partner selection: it is risky if your knowledge and experience in this field is limited (cost, technology, process); if you are looking at local providers, depending on your location, you may or may not have access to a big pool of providers.
4. On-site presence: some documentation (for example, printer manuals) require that your writers be on site from time to time to test the equipment.
5. There is a lack of collaboration tools to support distant teams and more importantly to organize efficient reviews. Hopefully, LiveTechDocs can help here!
Should you give it a try?
For big companies, it depends (I know that's an easy one):
* If you have divisions located where it is hard to find good tech writers, then you may consider it. HP Spain, for instance, decided to use an exclusive outsourcing partner to manage their printer documentation.
* Good option if you have high variability in workload.
* If the documentation is tightly integrated into your product or service and require frequent care, then avoid it. For instance, Salesforce uses the Agile development process with shorter release cycles.
SMBs, consider the following:
* If you have trouble accommodating with workload fluctuations and hiring an extra-employee does not make economic sense. The smaller the documentation team, the more relevant this is.
* If your documentation project is a "one-of" task why hire a full-time writer.
* If you lack the expertise in house, outsourcing is a viable option.
Outsourcing options
Who should you outsource to? Well, your options mainly depend on the size of the project and the type of relationship you want to develop:
* Big projects: go for the big guys (LionBridge, SDL...)
* Small to medium repetitive projects: select a business partner that can accommodate the sporadic workload; be aware of your negotiation power (i.e.: how important you are to this partner)
* Small to medium "one shot" project: consider single contractors or small boutiques
The next question is where to find your partner.
* Locally: this is usually easier to manage since the partner can be on site when needed; all it takes is an add on Craigslist!
* In the US: you may get arbitrage opportunities as costs for writers fluctuate between regions (ex.: Silicon Valley against the Mid West)
* Abroad: writers in Canada used to be affordable but a current weak-dollar is changing the rules of the game.
* On the Internet: it is a fast, easy, and cheap approach; check oDesk.com or Elance.com
Conclusion
There are a few compelling reasons to consider technical writing as a candidate for outsourcing: the process is simple enough, well understood, and documentation standards such as DITA and DocBook bring the flexibility needed to share and exchange documentation. However, there are also drawbacks: no previous outsourcing experience, inability to qualify providers, internal process or technologies that do not work well with outsourcing, and a lack of collaboration tools.
My belief is that in the future, documentation will be more open, fragmented, and integrated to the company product or service. Firms leading in their industry will use technology as a way to connect with users. As a result, outsourcing could be far less attractive.
Technical Projects Assistance In The Software Industry
Success of a masterpiece depends up on how it is architected. Any artifact and event need to be architected to take care of its fundamental and advanced need. Information Technology is more familiar with the word product architecture that project architecture. In some cases project architecture is used in case of product architecture considering that both is same.
We all know that Software product needs an architect but can we architect a Software project? Architecting a software product involves designing the product to be scalable, reliable and maintainable product. Who is responsible for cost effectively executing the project? Who will control the changes coming in the project? Who is responsible for overall execution?. Who will ensure that the client got the right product? How will we give value added idea to run the business of the client? Who will control the scope of the project?
This article defines a role for architecting a project that is the answer for all the above concerns.
Role of a project architect
One of the major reasons for the failure of a million dollar project is the lack of execution maturity. There are lots of maturity models/patterns available in the industry. CMM, CMMI, PCMM, RUP and Six Sigma are some of the industrially accepted standards. All of this standards defines the processes followed in the project, but does not hold with the dynamics of the projects, means the strategy of execution. Execution is different in different projects but it involves a common doctrine.
Every project except software project has defined a role called project architect. In software it is categorized separately as technical architect and that person will be only responsible for giving technical direction. Project manager will be overwhelmed by other responsibilities like Scheduling, Man management, Status Reporting and that role may not have bandwidth to think about execution.
Appropriate execution defines a need for defining a new role in the project called project architect. Project architect is the architect of project execution Project architect over sees the project in a detailed manner and understands nitty-gritty of the project and decided the course of action of the project. Project architect keeps a different perspective of project activities than a project manager. When project manager works on giving a workable environment for the team and track the schedule to identify any slippage, project architect work on taking the right decision or action in the project by closely analyzing the cost incurred in the project.
Project Architect should help project manager to understand what type of resources for what functionality is required. What is the grey area in the project? Which all areas we need commitment from customer. What is the root cause for an issue? Usually these areas are always handled by project manager along with other responsibilities and in turn giving a very secondary importance to the critical aspects of the project. By introducing project architect for this role, we are isolating and handling the most important and critical aspect of a project called project execution.
Responsibilities of a Project Architect
Project architect is responsible for the execution of the project. Project Architect should know each and every detail in the project. Below are the defined responsibilities of a project architect
• How to define which is cost effective path of execution?. It involved analyzing each and every activities and functionalities and identifies which is required path of execution.
• Project architect should have detailed business knowledge on all the modules so that responsible for identifying any dependency in the project.
• Conveys what is the technical problem in the project to technical team. Project Architect may not be the solution provider.
• Identify what is a change request and what is a requirement in the project.
• Identify business gaps in the project. Requirements can be captured to finest details but there can be still gaps in the understanding between the IT and the users. This gap has to be resolved during design phase. It is the responsibility of project architect to have the no gaps in the project after design phase.
• Analyze the cost/profit incurred in the project. Cost effective Execution also depends on the Cost /Profit Analysis of the project. For e.g. below graph provides idea of what is cost incurred in each week or phase.
Project manager can track cost and report the management when te cost is going above the expected limits. If a person has to architect the project in a cost effective manner for, he or she should know each and ever details of the project. If the project manager is spending time on that then the project will get executed in an uncontrolled manner. Considering project manager on this role is devastating.
Responsibilities of other roles in the Project
Account Manager:
Account Manager is responsible for stabilizing the account through effective client interaction Account Manager spends more time on the critical project with the project manager. He or She works above the hierarchy reporting the issues to the senior management.
Project Manager:
Project Manager is the owner of the project. Project Manager works with the support group for giving the environment for people to work and motivating the people. Project Manager is responsible for schedule tracking, procurement management, quality management, risk management, resource management etc.
Project Leader:
Responsible for making sure the project follows the right model. Responsible for deliverables of the project. Project Leader leads the team down the hierarchy working more with the team. Focus more on the critical path of the project. Project Leader is responsible for maintaining the quality of the product.
Technical Leader/Technical Architect:
Responsible for the design of the individual modules and owns the code devolved in the project. Technical Architect is responsible for taking the technical decision, creating a development habit among team members like good coding habits, enforcing the use of appropriate technology etc.
Architecting a Software Project.
Project Architect should know the requirements in detail, technical challenges, and dependencies with other departments before identifying the path of execution. With the mentioned details, project architect should be capable of judging the scope creep, critical path, most profitable path and resource utilization with in the project.
Project Architect need to be very diligent in watching the scope creep in the project. Scope Creep usually comes in the form of requirement changes. Change can come in any of the following ways.
1) Request not captured properly which creates a dilemma on whether it is change request or not.
2) Identifying the gaps in the project and removing it in the course of time. This is the toughest part of the project. Project architect can proactively take steps to reduce the gaps but removing it completely may not be possible.
3) Introducing new requirement to the project with out following proper Change Control Mechanism. Change requests are one of the profitable sources in a project. It need to be managed properly
Issue tracking through execution
We can only control the bugs/issues by proper execution but we cannot stop it completely. The important thing is to have a tracking mechanism. When an issue occur, the project manager increases the number of resources thinking that there is no efficient way to solve the problem other than increasing the hours. At that time there is no right person to identify the root cause of the problem. Project architect should own these issues in the project. Execution is not giving pat in the back of the people. Execution is not building a process and blindly following that. Execution is identifying the right process by properly analyzing the project and following it in a proper manner.
Reactive and Proactive approach for the project.
Project architect is a doer not a talker. Project architect is not only a problem solver but a person who avoids problem. By defining a role as project architect, we are introducing a person to be responsible for all the proactive and reactive aspects of the project. Project architect will own the executive decision of the project and identify way to tackle in the right way. Usually we define project leader as person to do things right and project manager to do right things. In a bigger perspective person who can do things right can only do right things. So defining a role called project architect, we are introducing a role just to do things right and right things in a project.
We all know that Software product needs an architect but can we architect a Software project? Architecting a software product involves designing the product to be scalable, reliable and maintainable product. Who is responsible for cost effectively executing the project? Who will control the changes coming in the project? Who is responsible for overall execution?. Who will ensure that the client got the right product? How will we give value added idea to run the business of the client? Who will control the scope of the project?
This article defines a role for architecting a project that is the answer for all the above concerns.
Role of a project architect
One of the major reasons for the failure of a million dollar project is the lack of execution maturity. There are lots of maturity models/patterns available in the industry. CMM, CMMI, PCMM, RUP and Six Sigma are some of the industrially accepted standards. All of this standards defines the processes followed in the project, but does not hold with the dynamics of the projects, means the strategy of execution. Execution is different in different projects but it involves a common doctrine.
Every project except software project has defined a role called project architect. In software it is categorized separately as technical architect and that person will be only responsible for giving technical direction. Project manager will be overwhelmed by other responsibilities like Scheduling, Man management, Status Reporting and that role may not have bandwidth to think about execution.
Appropriate execution defines a need for defining a new role in the project called project architect. Project architect is the architect of project execution Project architect over sees the project in a detailed manner and understands nitty-gritty of the project and decided the course of action of the project. Project architect keeps a different perspective of project activities than a project manager. When project manager works on giving a workable environment for the team and track the schedule to identify any slippage, project architect work on taking the right decision or action in the project by closely analyzing the cost incurred in the project.
Project Architect should help project manager to understand what type of resources for what functionality is required. What is the grey area in the project? Which all areas we need commitment from customer. What is the root cause for an issue? Usually these areas are always handled by project manager along with other responsibilities and in turn giving a very secondary importance to the critical aspects of the project. By introducing project architect for this role, we are isolating and handling the most important and critical aspect of a project called project execution.
Responsibilities of a Project Architect
Project architect is responsible for the execution of the project. Project Architect should know each and every detail in the project. Below are the defined responsibilities of a project architect
• How to define which is cost effective path of execution?. It involved analyzing each and every activities and functionalities and identifies which is required path of execution.
• Project architect should have detailed business knowledge on all the modules so that responsible for identifying any dependency in the project.
• Conveys what is the technical problem in the project to technical team. Project Architect may not be the solution provider.
• Identify what is a change request and what is a requirement in the project.
• Identify business gaps in the project. Requirements can be captured to finest details but there can be still gaps in the understanding between the IT and the users. This gap has to be resolved during design phase. It is the responsibility of project architect to have the no gaps in the project after design phase.
• Analyze the cost/profit incurred in the project. Cost effective Execution also depends on the Cost /Profit Analysis of the project. For e.g. below graph provides idea of what is cost incurred in each week or phase.
Project manager can track cost and report the management when te cost is going above the expected limits. If a person has to architect the project in a cost effective manner for, he or she should know each and ever details of the project. If the project manager is spending time on that then the project will get executed in an uncontrolled manner. Considering project manager on this role is devastating.
Responsibilities of other roles in the Project
Account Manager:
Account Manager is responsible for stabilizing the account through effective client interaction Account Manager spends more time on the critical project with the project manager. He or She works above the hierarchy reporting the issues to the senior management.
Project Manager:
Project Manager is the owner of the project. Project Manager works with the support group for giving the environment for people to work and motivating the people. Project Manager is responsible for schedule tracking, procurement management, quality management, risk management, resource management etc.
Project Leader:
Responsible for making sure the project follows the right model. Responsible for deliverables of the project. Project Leader leads the team down the hierarchy working more with the team. Focus more on the critical path of the project. Project Leader is responsible for maintaining the quality of the product.
Technical Leader/Technical Architect:
Responsible for the design of the individual modules and owns the code devolved in the project. Technical Architect is responsible for taking the technical decision, creating a development habit among team members like good coding habits, enforcing the use of appropriate technology etc.
Architecting a Software Project.
Project Architect should know the requirements in detail, technical challenges, and dependencies with other departments before identifying the path of execution. With the mentioned details, project architect should be capable of judging the scope creep, critical path, most profitable path and resource utilization with in the project.
Project Architect need to be very diligent in watching the scope creep in the project. Scope Creep usually comes in the form of requirement changes. Change can come in any of the following ways.
1) Request not captured properly which creates a dilemma on whether it is change request or not.
2) Identifying the gaps in the project and removing it in the course of time. This is the toughest part of the project. Project architect can proactively take steps to reduce the gaps but removing it completely may not be possible.
3) Introducing new requirement to the project with out following proper Change Control Mechanism. Change requests are one of the profitable sources in a project. It need to be managed properly
Issue tracking through execution
We can only control the bugs/issues by proper execution but we cannot stop it completely. The important thing is to have a tracking mechanism. When an issue occur, the project manager increases the number of resources thinking that there is no efficient way to solve the problem other than increasing the hours. At that time there is no right person to identify the root cause of the problem. Project architect should own these issues in the project. Execution is not giving pat in the back of the people. Execution is not building a process and blindly following that. Execution is identifying the right process by properly analyzing the project and following it in a proper manner.
Reactive and Proactive approach for the project.
Project architect is a doer not a talker. Project architect is not only a problem solver but a person who avoids problem. By defining a role as project architect, we are introducing a person to be responsible for all the proactive and reactive aspects of the project. Project architect will own the executive decision of the project and identify way to tackle in the right way. Usually we define project leader as person to do things right and project manager to do right things. In a bigger perspective person who can do things right can only do right things. So defining a role called project architect, we are introducing a role just to do things right and right things in a project.
Friday, February 29, 2008
Applications In The Field Of Technical Project Management
Some projects are the function of unusual circumstances or occur less frequently than most other computing activities. These types of applications fall under the heading of “Special Projects” in the field of project management. Examples include system integration due to mergers or acquisitions, application reengineering, and the well-known year 2000 conversion. Managing these types of projects can challenge even the most experienced and seasoned of professional. Sometimes, there is a tendency to administer similar procedures as those used for more standard projects and the results can be less favorable than expected. The most important aspect to remember in these situations is that project management should not be exercised in such a way that it ignores the peculiar aspects of such one-time projects.
Project management cannot be viewed as a solitary management activity but rather a set of dynamic principles that can be cultivated and improved through practical experience. Ignoring the need for continuous improvement would be as detrimental as ignoring the basic principles for applying project management itself.
On the other hand, it is yet another facet of the intricate process that defines the overall manner of project management. Despite the obvious need for managing projects and the necessity to improve the process, many organizations continue to fail in the consistent and repeatable application of project management principles. This may be due, in part, to the overwhelming difficulties of technical projects, partial success, or misunderstanding the evolution of the project management life cycle. Nevertheless, without a commitment to measurement, further improvements to project management efforts will stagnate and organizations will rely on ineffective techniques to manage computing activities.
Planning the project management activities for the challenges of tomorrow’s business environment will remain difficult, but not impossible. Opinions and predictions about future computing technology or shits in economic direction should be viewed cautiously, especially since many predictions tend to confuse rather than aid in project management endeavors. For those of us who have earnestly pursued the rigors of managing projects, it has demanded the best of our skills, including the dedication to succeed.
From my own experiences as a senior IS executive, I appreciate the challenges that project management poses in a time of rapid, yet exciting technical change. I hope you continue researching project management strategy to gain important concepts that add knowledge to your existing expertise, as well as provide you with the tenacity to improve your management skills.
Technical Projects In Software By Techno Architects
Success of a masterpiece depends up on how it is architected. Any artifact and event need to be architected to take care of its fundamental and advanced need. Information Technology is more familiar with the word product architecture that project architecture. In some cases project architecture is used in case of product architecture considering that both is same.
We all know that Software product needs an architect but can we architect a Software project? Architecting a software product involves designing the product to be scalable, reliable and maintainable product. Who is responsible for cost effectively executing the project? Who will control the changes coming in the project? Who is responsible for overall execution?. Who will ensure that the client got the right product? How will we give value added idea to run the business of the client? Who will control the scope of the project?
This article defines a role for architecting a project that is the answer for all the above concerns.
Role of a project architect
One of the major reasons for the failure of a million dollar project is the lack of execution maturity. There are lots of maturity models/patterns available in the industry. CMM, CMMI, PCMM, RUP and Six Sigma are some of the industrially accepted standards. All of this standards defines the processes followed in the project, but does not hold with the dynamics of the projects, means the strategy of execution. Execution is different in different projects but it involves a common doctrine.
Every project except software project has defined a role called project architect. In software it is categorized separately as technical architect and that person will be only responsible for giving technical direction. Project manager will be overwhelmed by other responsibilities like Scheduling, Man management, Status Reporting and that role may not have bandwidth to think about execution.
Appropriate execution defines a need for defining a new role in the project called project architect. Project architect is the architect of project execution Project architect over sees the project in a detailed manner and understands nitty-gritty of the project and decided the course of action of the project. Project architect keeps a different perspective of project activities than a project manager. When project manager works on giving a workable environment for the team and track the schedule to identify any slippage, project architect work on taking the right decision or action in the project by closely analyzing the cost incurred in the project.
Project Architect should help project manager to understand what type of resources for what functionality is required. What is the grey area in the project? Which all areas we need commitment from customer. What is the root cause for an issue? Usually these areas are always handled by project manager along with other responsibilities and in turn giving a very secondary importance to the critical aspects of the project. By introducing project architect for this role, we are isolating and handling the most important and critical aspect of a project called project execution.
Responsibilities of a Project Architect
Project architect is responsible for the execution of the project. Project Architect should know each and every detail in the project. Below are the defined responsibilities of a project architect
• How to define which is cost effective path of execution?. It involved analyzing each and every activities and functionalities and identifies which is required path of execution.
• Project architect should have detailed business knowledge on all the modules so that responsible for identifying any dependency in the project.
• Conveys what is the technical problem in the project to technical team. Project Architect may not be the solution provider.
• Identify what is a change request and what is a requirement in the project.
• Identify business gaps in the project. Requirements can be captured to finest details but there can be still gaps in the understanding between the IT and the users. This gap has to be resolved during design phase. It is the responsibility of project architect to have the no gaps in the project after design phase.
• Analyze the cost/profit incurred in the project. Cost effective Execution also depends on the Cost /Profit Analysis of the project. For e.g. below graph provides idea of what is cost incurred in each week or phase.
Project manager can track cost and report the management when te cost is going above the expected limits. If a person has to architect the project in a cost effective manner for, he or she should know each and ever details of the project. If the project manager is spending time on that then the project will get executed in an uncontrolled manner. Considering project manager on this role is devastating.
Responsibilities of other roles in the Project
Account Manager:
Account Manager is responsible for stabilizing the account through effective client interaction Account Manager spends more time on the critical project with the project manager. He or She works above the hierarchy reporting the issues to the senior management.
Project Manager:
Project Manager is the owner of the project. Project Manager works with the support group for giving the environment for people to work and motivating the people. Project Manager is responsible for schedule tracking, procurement management, quality management, risk management, resource management etc.
Project Leader:
Responsible for making sure the project follows the right model. Responsible for deliverables of the project. Project Leader leads the team down the hierarchy working more with the team. Focus more on the critical path of the project. Project Leader is responsible for maintaining the quality of the product.
Technical Leader/Technical Architect:
Responsible for the design of the individual modules and owns the code devolved in the project. Technical Architect is responsible for taking the technical decision, creating a development habit among team members like good coding habits, enforcing the use of appropriate technology etc.
Architecting a Software Project.
Project Architect should know the requirements in detail, technical challenges, and dependencies with other departments before identifying the path of execution. With the mentioned details, project architect should be capable of judging the scope creep, critical path, most profitable path and resource utilization with in the project.
Project Architect need to be very diligent in watching the scope creep in the project. Scope Creep usually comes in the form of requirement changes. Change can come in any of the following ways.
1) Request not captured properly which creates a dilemma on whether it is change request or not.
2) Identifying the gaps in the project and removing it in the course of time. This is the toughest part of the project. Project architect can proactively take steps to reduce the gaps but removing it completely may not be possible.
3) Introducing new requirement to the project with out following proper Change Control Mechanism. Change requests are one of the profitable sources in a project. It need to be managed properly
Issue tracking through execution
We can only control the bugs/issues by proper execution but we cannot stop it completely. The important thing is to have a tracking mechanism. When an issue occur, the project manager increases the number of resources thinking that there is no efficient way to solve the problem other than increasing the hours. At that time there is no right person to identify the root cause of the problem. Project architect should own these issues in the project. Execution is not giving pat in the back of the people. Execution is not building a process and blindly following that. Execution is identifying the right process by properly analyzing the project and following it in a proper manner.
Reactive and Proactive approach for the project.
Project architect is a doer not a talker. Project architect is not only a problem solver but a person who avoids problem. By defining a role as project architect, we are introducing a person to be responsible for all the proactive and reactive aspects of the project. Project architect will own the executive decision of the project and identify way to tackle in the right way. Usually we define project leader as person to do things right and project manager to do right things. In a bigger perspective person who can do things right can only do right things. So defining a role called project architect, we are introducing a role just to do things right and right things in a project.
Subscribe to:
Posts (Atom)