‘The only good thing to do with good advice is pass it on; it is never any use to oneself” – Oscar Wilde
“Fragments of Knowledge” complement and supplement the more wide-ranging knowledge provided in the categories you’ll find in “Nuggets”. They align with the ‘Simple Knowledge; Simply Conveyed’ ethos of this website.
Fragments of Knowledge, just like Nuggets, are learning derived from practitioner experience. They are presented as ‘5 Essentials on…’ to provide a particular focus on a more granular topic than you’ll see in Nuggets. Read on below and you’ll get the gist! Alternatively, look at the Badger’s ‘Fragments of Knowledge’ series of short videos on YouTube.
Be sure to check back here or on YouTube every so often to see what’s new…
5 Essentials for software programming
- Design the software module to meet its specified functionality and be maintainable, efficient, robust, reliable, portable and changeable before starting to write code.
- Have, and comply with, a coding convention and standard that embodies proper naming conventions, avoids hard-coding of parameters, and advocates the use of simplicity rather than complexity wherever possible.
- Embed useful comments, including a header that describes the module’s name, purpose, author, creation date, how it works, an amendment log and any relevant copyright or IPR statement. Use comments to aid knowledge transfer to, and maintenance by, others.
- Conduct a formal code review prior to module completion with an appropriate independent person to identify design, programming and coding convention/standard issues. Fix any deficiencies found.
- Use strict version control and thoroughly test the module to show it meets its functional, design and performance requirements, and that it handles error conditions gracefully. Keep all development and testing records.
5 Essentials for selecting a software product/kernel supplier
- Be clear on the difference between a ‘product’ and a highly configurable and customizable ‘kernel’ and decide which is required to satisfy your overall need.
- Set out the functions and technical criteria you want a product/kernel to fulfil in a requirement document and search the market and your pre-existing supplier relationships to identify potential candidates.
- Conduct a formal competitive procurement exercise that includes a thorough financial, legal and technical due diligence on the suppliers before deciding on the preferred product/kernel and supplier.
- Insist on a formal product demonstration by the supplier and visit one or more reference sites where the product is in use with end users. Do this and be comfortable with the outcomes before signing any contract with the supplier.
- Sign a contract which has a clear, unambiguous written scope and clear terms regarding licensing, delivery timeliness, product/kernel upgrades, warranties and maintenance. Niche or specialist products from small companies or start-ups with a low installed-base are always a risk; always have a fall-back product option as a post-contract contingency measure.
- Read and understand the Terms & Conditions, and always take advice from your legal adviser on their acceptability.
- Read and understand a) the full scope of what is to be delivered, when, and how changes are agreed, and b) what has been subcontracted and under what terms.
- Read and understand written dependencies on your client and other 3rd parties and how your risks are flowed down to any subcontractor(s).
- Read and understand when and how you get paid, any financial penalties for lateness, and your obligations to pay subcontractors.
- Read and understand your overall liabilities, especially in circumstances of contract termination and exit at the end of the contract term. Confirm with your legal adviser that the contract can be signed, and then sign it.
- Know your audience; orient what you are going to say and slides for your subject to be as easy for the audience to engage with you and your subject as possible.
- Remember that people rarely concentrate on a subject for more than ~40 mins in one go, and that a good rule of thumb is that it takes about 3 minutes to talk to a slide.
- Structure your presentation to have a beginning, a middle, and an end; summarise and reinforce the key points you want your audience to take away at the end.
- Make slides engaging; use pictures and/or video snippets relevant to the subject; keep text short, bulletized, readable and focused on the points you want to make.
- Think about what techniques (e.g. jokes, anecdotes, demonstrations etc) you will use to grab and keep your audience’s attention while you are speaking; rehearse your speech with your slides before giving the presentation for real.
5 Essentials if you suspect there is an unreported problem or issue that may require intervention
- Watch the behaviour of people who may be associated with the potential problem and look out for unusual stresses, strains, and work patterns.
- Listen to what people are talking about; for example, passing comments in meetings, coffee point gossip, and chatter at formal and informal gatherings.
- Look at formally reported information, such as financial status and trends, delivery metrics, and client relationship (for example).
- Make preparations to intervene if warranted; plan and prepare the action to be taken, when it should happen, what the intended outcome is, and how impacts on people and/or clients are to be handled.
- Execute the intervention as planned explaining to those affected the rationale for the action being taken and how it affects them.
5 Essentials at the heart of creating a rudimentary software development plan
- Have a clear understanding of the scope, functionality, and software architecture, as well as the software development methodology, standards and supporting tools to be used.
- Estimate the amount of software to be developed for each component in the software architecture using a consistent, relevant and widely understood metric.
- Calibrate the results against estimates produced completely independent by at least one independent expert who is not associated with your project; reconcile differences.
- Compare estimates with real metrics from similar projects completed successfully by your enterprise. Make comparisons intelligently and decide the final software estimate that will form the baseline for your plan.
- Convert the baseline software estimate into effort and time. Use, wherever possible, suitable productivity metrics for the software gleaned from other successful projects, and always base effort on average people, working normal office hours, and always allow for sickness, vacations and national holidays – assess the resulting plan using a parametric model (e.g. SLIM) for major software developments.
5 Essentials for a service provider considering taking on a new outsource
- Work with the client to understand their forward business case and their existing service arrangements; analyse fully the formal information provided in the client’s data room – seek clarification and ask questions formally and in writing.
- Undertake a thorough due diligence activity to validate information about the current service; always validate information about the existing IT estate and applications and include site/installation visits in this process – pay particular attention to software licencing.
- Analyse suppliers and subcontractors to the current outsource and assess their importance, or otherwise, to the ‘to be’ service; ensure any changes are included in costings.
- Analyse the client or incumbent service provider staff in scope of the outsource; use HR professionals for this and pay special attention to TUPE (or equivalent in other countries), pension arrangements and trade unions.
- Ensure you can meet required Service Levels/KPIs at a competitive price and that you understand the contract liabilities for non-performance; always understand your responsibilities for in-flight projects, transition from an incumbent, and transformation or technology refresh before signing a contract with a competitive price.
5 Essentials before ‘Going Live’
- Ensure all required functional and non-functional tests have completed successfully and met the required and expected outcomes; pay particular attention to security, safety and privacy testing.
- Validate that all critical and serious defects that arose from testing are fixed, tested and included in the production build that has subsequently completed regression testing successfully.
- Verify that any data transformation, data loading and data migration has been conducted in line with a specified strategy and has completed successfully.
- Confirm the client and its users have completed training for using what is going live, understand the introduction to service strategy and approach, and are ready for the impact on their business of live operation.
- Ensure that you are clear on how post-live help, support, problem management, warranty and defect fixing will happen and validate that the mechanisms to do this are ready and in place before the first day of live operation.
5 Essentials of security-conscious personal behaviour
- Know your enterprise’s security policies, processes and procedures and comply fully with these and – if they apply – government/defence/intelligence security clearance and classified information rules and regulations. Be proud to comply!
- Do not talk to anyone about sensitive or formally classified work unless you know they are authorised to know and they have a ‘need to know’.
- Use relevant, robust and secure protection measures when storing or transporting any sensitive or formally classified information. Do not store or work with formal, highly classified information at home.
- Security is your responsibility not someone else’s. Always be watchful at work and in public for unusual or strange behaviour and report it. Apply common sense to everything you see or do.
- If you travel internationally then always check your government’s advice covering security and personal safety in the countries you plan to visit before you travel. Comply with the advice, remember items 1 to 4 above, understand cultural differences, travel light so you can move fast if necessary, and always avoid known high crime areas and areas known to be antagonistic to your home country.
- Take steps to understand their culture; respect their culture and the how it influences the way people behave and work.
- Work within their culture to make things happen; don’t expect people in different countries to instantly understand your own culture and ways of working.
- Communicate well, clearly, and frequently and check that what you have communicated has been received and understood correctly.
- Visit people in their home countries, if possible, to build strong personal relationships and trust.
- Don’t expect the Western motivations and approach to negotiations to be successful everywhere in the world, and don’t expect Yes to always mean Yes!
- Always remember that no matter how friendly they are, a journalist is not your friend. Ask to have sight of their ultimate article before publication. They may not agree but you should always ask.
- Prepare what you want to say regarding the subject of your interview, and the key messages you want to get over. Stay ‘on message’ during the interview at all times.
- Always remember that the journalist is looking for a story, and not necessarily a story relevant to the subject of the interview. Stay on message – don’t be deflected.
- If questions arise that you are not prepared for or don’t want to answer then say so. Never waffle or allow yourself to be manoeuvred to provide ill-considered answers.
- Never lose your temper. Stay calm, collected and on message no matter how difficult that is. If you lose your temper or terminate the interview prematurely the journalist will still have something to write about!