Mostrar mensagens com a etiqueta Deliverables. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Deliverables. Mostrar todas as mensagens

quarta-feira, 7 de março de 2018

SECURITY: The visible face of your projects could be the wrong one

Customer are always important but some customers and its projects will need additional care. Sometimes the visible face of your work gets into the news and this is good. Unless the news are bad, or even worse, are incorrect.

Only then you'll probably be aware that sometimes it is just not a matter of being the best in business and let your technical (and management) competency excel.
It's a matter of surviving what it is being said about your work, the way you got your contract, the way you delivered your work, the way you could get the blame for issues that are not part of the scope of your work and so on. It's then that you'll have to have your executive management support (to shield you from the outer world interferences and to manage communication with that outer world).

The oddest experience I've ever had was having to work with a point of contact that was to help us execute a specific project and from minute one his intentions were to undermine the project's success. I had 20+ years of experience in the software industry, and in my innocence, I was thinking I had nothing more to learn. I was so wrong,

What if the visible face of your project start to be in the news? The news could be correct and/or incorrect; presenting sensitive data and/or confidential data (that no one knows who's disclosing). Your competition could be interested in it. Internal stakeholders could be interested in it (feeling "invaded"). Reporters could be getting it all wrong. It can get messy...

Some examples (in PT, sorry guys):
Maybe some more can be told on this topics later on. Lessons learned are for sure more useful if properly shared. And you bet that we've managed to deliver successfully that particular [migration] project.

Revisions: 2018-03 - updated links. 2018-04 - added the "drop money out of the window" link.
PS: Additional info or how to not execute a "data migration" project:



quinta-feira, 28 de abril de 2016

Main Work Products for Software Development Projects (Waterfall)

The waterfall phases aim to define:
- What to do? - requirements catalogue (mapping to features; features could map to requested features)
- How to do? - high-level architecture and (if needed) detailed design
- Execute! - produce the code, unit tests and reverse engineer the detailed design (if possible)
- Validate! - validate the system against requirements (are we doing things right?)
- Accept! - prove that the system solves the customer problems (to the customer or a customer representative). Are we doing the right things? Deploy (transfer).
- Maintain! - keep the system up and running (and optionally evolve it - new features, changed features)

The core work products (outputs of applying QMS Engineering processes) are:
- SRS (Requirements Spec)
- SAS (Architecture Spec document - High Level Design; could include sections for ICD, DBS)
- SDD (Detailed design which could include a section for the DBS)
- The Code
- STS (and the STR, i.e. the test report)
- ATS (and the ATR)

In order to execute the project you'll also need plans (management documents, outputs of applying QMS Management or QMS Support processes) as well as present reports:
- PMP (Project Management Plan),
- CMP (Configuration Management Plan);
- CIL (identifies the review strategy for each item - and lists external CIs)
- QAP (Quality Assurance Plan)
- SVP (SVVP, and some similar docs could exist due to regulatory requirements)

- SPAR (SW Product Assurance Report - metrics per milestone)
- Milestone Reports
- Progress Reports (per milestone or per time period - e.g. monthly)
- etc.

PS. Remember that not all these documents need to be deliverables: A Deliverable requires extra peer review and formal customer acceptance (and all this takes you away precious time). Typically the project proposal identifies the minimum set of deliverables.

(@2016-10-13: rephrases, expanded acronyms)