Many issues can occur before, during and after the completion of a project that can affect the client's perception of its success. Knowing the risks that lie within a project allows you to take measures to prevent them from becoming an issue, or at least contain them from becoming more serious than they need to be.
Not all projects are equal, and this is certainly the case when it comes to software projects. If you are creating an entertainment app such as a smartphone game, making the app enjoyable to use will be a top priority, whereas creating an air traffic control software will not have any emphasis on enjoyability and will instead focus more on issues such as reliability, scalability and fallback safety features for scenarios where system components fail. These examples show how diversified software projects can be, and hence how their relevant risks should dictate the style of project management.
Most projects where there is more than one person involved will have an element of politics to some degree. We've already covered how this can happen with clients for whatever reason, but it can also happen with people in the development team, whether it be with project managers, designers or programmers. Like with clients, the majority of project politics are caused by the different visions of the people who are progressing the project and assumptions made. The following are typical areas that should be managed by the team project manager:
- Decision by committee:
- With your role as software developer being central to all other activities on the project, it is difficult to avoid getting involved in the politics between other members; this not only affects your productivity, but can also lead to the introduction of faults within your code and you being held responsible for actions of other people.
- Decision by committee also reduces how fast the team can respond to the need for change. At its worst, team members can become undisciplined in order to achieve their agenda to a point that they are destructive to the project's progression; an example of this being features not designed to the project specification because members on the project are too emotionally attached and as a result are designing the system as their own product instead of as a product for the client.
- Solutions for decision by committee should include:
- Identifying someone to become the dedicated decision maker. This person will liaise with the client to acquire information about their ongoing requirements, and will closely monitor progress of the creative/development team to ensure that what is being developed matches the project specification. This person would also be responsible for monitoring all communications regarding the development of system features to ensure that scope for misinterpretation or manipulation can be minimized.
- Ensuring that members of the project are not emotionally attached to the project, whether it be having an agenda to create the system primarily for their portfolio, or where they are paid royalties – which motivates people to become personally attached to design and development decisions.
- Welcoming the input and suggestions of team members, as long as they are communicated through the team's decision maker for final decisions.
- Blame culture - When things aren't going well on a project, some types of people are more than willing to point the blame at the next person. With programming the software being central to the project, you should be aware of how this can put you in the firing line with such people. Look to have procedures in place that protect you from being the victim of these politics, which could include:
- Minutes taken in all meetings to ensure everyone has a record of what's been agreed.
- Having a document for confirming authorization to commence development of requested features, allowing you to show who made the requests if they are later disputed.
- Having a sign off document to confirm satisfaction of each completed milestone, allowing you to show that confirmation was given of completion to a satisfactory standard.
- Manipulation - Some people on a project team can be problematic due to having their own agenda. This becomes a serious issue if they are also capable of being deliberately manipulative, which can lead to situations where you are led to believe incorrect information that suits their agenda. An example: A freelance team member has an agenda to use the project to enhance their portfolio and to increase the amount they are paid from the project. Their motivations lead to the team member suggesting features that not only increase the requirements for their services, but are also complicated to develop and unnecessary for the client's requirements. The team member pushes their agenda to be developed into the project by telling you that their features have been requested and authorized by the client, leading to you coming under fire when it is discovered that unauthorized features or alterations have been developed into the software. As a result, the project extends from 3 months of development work to spread over 3 years due to extensive coding, testing and design requirements. In the worst case scenario, manipulation can lead to a dispute in a dispute with the client; if nothing has been signed, it could mean that you are left with thousands of pounds/dollars worth of your time unpaid. You can minimize the risk of this by taking the same measures for managing the blame culture, in which you have processes to document and verify all requests you are asked to develop. Make sure to also have spoken confirmation by main the main decision maker(s) in a conversation to eliminate the risk of signed documents being tampered with and/or requests being worded in a way that is misunderstood by you and/or the decision maker(s).
The most important element of managing any project is setting expectations for what will be delivered. Get this wrong and you set yourself to fail before you've started the project. The following are six areas to consider for evaluating the type of expectations you want to set for the client:
- Budget
- An ideal project would have an unlimited budget to allow the deployment of the best quality time, expertise and labor to progress the project to a successful completion of the highest quality. Although an unlimited budget wouldn't always guarantee access to the best resources, it would certainly go a long way to make it possible if used wisely with knowledge.
- The problem with real world projects is that they are almost always affected by an available budget. Whether it is due to cash flow or profit margins, money is one of the two main factors that affect what is possible. Good project management allows for money to achieve more results through higher efficiency and productivity, but there will always be a limit to what a budget can achieve, so make sure you set expectations to be realistic on what a budget can achieve and don't let yourself be bargained down by clients who want to get the lowest price. Even if you lose a project bid to someone quoting an unrealistically low price, you can still be there to offer your services when it all goes wrong and without needing to worry about being out of pocket or vulnerable to legal action resulting from how the budget limits you from fulfilling your obligations.
- Time
- The other major factor affecting capabilities to meet expectations is time, which itself is closely related to budget – time is money as they say! Time may be limited due to budget restrictions, or it may be limited due to the need to meet a completion deadline. Either way, clients need to be aware of what is realistically achievable within the available time. Software features can also be labeled in order of their importance so that less required features can be dropped or delayed for a future release should there be any slippage in the project plan – see more about this in Chapter 10, Software Development Methodology.
- Skills and knowledge
- Whether it's your own skills or people you are working with, being realistic about your capabilities will allow you to avoid allowing the client to expect more than what you are capable of delivering. Although skills and knowledge can be gained through the lifespan of the project, there is a time requirement to develop such skills and knowledge to a standard where it can be usefully deployed within the project. This is where more experienced developers can justify their higher costs through an ability to deliver more productively, hence lowering the real overall costs for developing advanced code components that a more junior level developer would require more time to deliver.
It is important to identify that the skills and knowledge required by the software project fall into three categories:
Development—i.e. knowledge and skills for writing writing code.
Industry—i.e. knowledge and skills about the client's industry, customers and competition that will allow you to make better judgments about the software requirements and implementation.
Soft—i.e. the people skills for knowing how to manage the client and retain their confidence.
- Skills and knowledge can also be used to develop resources that allow for better productivity. This may be in the form of content generation tools that allow data required by the software in development to be created through drag and drop GUI based input instead of manually entering code or data, or tools that capture client input to avoid inefficiencies such as duplication of work or features that are dropped from the requirements after they have been developed.
- Whether it's your own skills or people you are working with, being realistic about your capabilities will allow you to avoid allowing the client to expect more than what you are capable of delivering. Although skills and knowledge can be gained through the lifespan of the project, there is a time requirement to develop such skills and knowledge to a standard where it can be usefully deployed within the project. This is where more experienced developers can justify their higher costs through an ability to deliver more productively, hence lowering the real overall costs for developing advanced code components that a more junior level developer would require more time to deliver.
- Technologies
- Enthusiastic clients often have big ambitions that match their enthusiasm, sometimes which can't be met with the technology available—whether it be availability within the budget or that the technology has yet to be developed. An example of the latter being how hardware for Internet of Things (IoT) are allowing new functionalities for software applications that wouldn't have been possible before 2010.
- Resources
- Resources are often related to technologies, especially when they are built on available technologies that the project uses, but they are separate to technologies in the sense that they are developed or customized to boost productivity ability of the project. This may include developing authoring tools to speed up data generation that the software in development relies upon; an example being a GUI point and click tool to capture image coordinates, avoiding the need to manually write code and test for ever co-ordinate for interactions. These resources appear within the project over time to make you and your team more productive, but are not immediately fully available unless you've already delivered projects to the same specification.
- Law and ethics
- Although something may be technically achievable, it may not be possible to legally or ethically deliver. Clients may ask for inappropriate features of their software such as an ability to hijack the host computer/phone to deliver advertising and capture details, which could be considered as illegal under the Computer Misuse Act 1990. Other requests may be completely legal, but raise ethical concerns depending on the views held by the public or the software developer. A website designer was once exposed in a local newspaper for being hired to create and manage an adult-themed website, which although not illegal, could have lost him potential business with other clients who would worry about having an association with the story tarnishing their brand. Being clear with clients from the start of the project about what can be lawfully and ethically achieved will avoid assumptions being made that put you in a difficult position once the project has commenced.
There is a hierarchy in which expectation factors affect each other, which is demonstrated in the following diagram:
It would be naïve not to expect something to go wrong in your projects, so understanding the implications of what can happen when delivery dates are missed and bugs within the code are left unnoticed will go a long way in allowing you to analyze the risks posed by being involved with the project. In the worst case scenarios, setbacks can leave you open to claims for:
- Loss of earnings : A client could claim that the delayed delivery of your software has led them to lose money from lost sales that they were expecting to make from the delivery date, and as a result could attempt to use the legal system to force you to compensate them for their calculated losses.
- Loss of business opportunities : Where faults in the software lead to data being lost, whether it be through data not being stored or data being deleted, the client could make a legal claim for compensation to the value of what they consider the lost data to be worth. Their compensation claim could be in relation to loss of opportunities to generate earnings, in which it they assume that each of the lost data items would have generated new business, or they could claim that the lost data is essential to their business operations, in which they would be claiming for compensation from lost productivity and business opportunities.
- Financial losses : Where faults in software lead to direct financial losses such as e-commerce websites dispatching orders without taking correct payments, or where the client is subjected to litigation resulting from software faults, the client could in turn take legal action against you to indemnify them against the claims they are subjected to.
Fortunately such claims are not so common and are only a higher risk where:
- The data being processed is highly sensitive or valuable—e.g. storing bank account details on the system database.
- The client deliberately causes problems with the software development process—potentially with a view to claim more money back from you than they are paying in the first place.
The solution to vulnerability to legalities is to have clauses in your terms and conditions that are specific to protect you against the types of situation that can occur. Care should be taken to ensure that your terms are worded accurately and in depth enough to cover the situations you are by default vulnerable to, as well as to reflect the law—your clauses are only valid if they are compliant with existing laws. Make sure to make your terms clearly understandable to eliminate any scope for the wording to be interpreted with a different meaning. A good set of terms and conditions should:
- Have an introduction section to define meanings of important words: This provides a clear definition of important words used in the agreement in a way that eliminates scope for the client to have the terms ruled invalid should it be taken to court based on a different interpretation of the wording.
- Be split into sections covering the main points of concern : Allows for easier interpretation and amendments if required. With the agreement being easier to interpret, it is also more likely to go in your favor if a dispute should go to court.
- Have a provision to set a limit on your liability : Should there be a situation where all other clauses fail, this provision can be used to make sure that your exposure is limited to what you deem acceptable. This could be limited to the value of the project or just a fraction of what you are being paid, and protects you against the rare but concerning client who hires you with the sole intention of claiming more money than they pay you. At a maximum, the limitation of liability clause should be set to no more than the value of your professional indemnity insurance cover.
- State the responsibilities of the client : For anything where you are responsible for meeting measureable expectations based on time or quality such as completion dates and assurances of working functionality, there should be a clause to state that delivery to the agreed criteria is dependent on adequate assistance from the client. This avoids situations you are held to account in failing to meet expectations due to the client failing to provide information, content and other resources you need to complete the work. For example, projects will exceed their agreed completion date if you are unable to progress work due to awaiting content or server access from the client.
- Make sure the client pays for work accepted : Your terms should have a clause to state that live usage of the work you have created for the client signifies its acceptance to the client's satisfaction and therefore any remaining payments under the agreement being due. This protects you against clients who use withholding payments to extend the project specification in order to receive free labor.
- Protect you against third party litigation : Anything that the client requests you to create or provides for integration with your creation should be the responsibility of the client. This may include provision of imagery, text content or code components that the client doesn't have permission to use. A clause in your terms and conditions to state that the client is responsible for the accuracy, ownership and/or permission to use the content they provide will protect you from copyright and defamation claims from third parties you have no involvement with.
- Distinguish between the immediate project delivery and ongoing maintenance and support : Clients will often have support requirements long after you have completed the delivery of their software. Having a clause that defines what level of support is provided makes it clear what support requests are acceptable and protects you against situations where you are expected to deliver support that would cost more time than you've been paid for the entire project, or where support requirements expose you to other legal issues. The support clause should clearly describe how long your initial support will last and the detail of activities that the support will cover, with additional support being purchasable under a separate agreement.
- Protect against acts of God : You only need to look at the news during most winters to realize that events such as severe flooding cause havoc. Although unlikely, these events don't just happen to other people and therefore could happen to you at a time critical to completing the client's project. Having a clause in your terms and conditions to state that the agreed timescales and delivery specification exclude occurrences of acts of God will protect you against any claims from the client relating to this.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.