"What project areas do you focus on?"
If you ask someone this question, consider it to be more of a brainstorming question that may be useful to conversationally and broadly introduce the topic of projects, but it is very important to not make this either a 'telepathy' question where we expect them to know what we mean by 'project areas' prior being provided with detailed documentation, or to expect or require any structured answer to such a vague question. This, and questions like this, are generally open ended questions to try to get a casual sense of what they might be most interested in and focused on. There is always a chance that their experience and thinking can be an important new addition to your tool kit. Others often hold the keys to our locked doors.
- Q: "Are there answers or is the person evasive?"
- Q: "Are the answers vague or clear?"
- Q: "Are the answers indeterminate?"
- What project areas do you focus on?
- How do you do needs and goals evaluations? (See: https://github.com/lineality/needs_goals_assessment_disambiguation)
- How are Features designed baring in mind types of systems?
- Process (e.g. workflow type, policies, procedures)
- Schedules (e.g. starting, stoping)
- Users/Stakeholders (e.g. Who are they?)
- Features, Needs & Goals (e.g. What are they?)
- MVP (e.g. What is the first Minimum Viable Product to build?)
- Feedback, Communication, Learning (e.g. using stakeholder feedback and identifying and acquiring needed skills)
- Process: Workflow Type, STEM Integration & Data-Definitions, Values, Agenda, Methods, Policies (including for predictable issues problems and collapse elements: scope-churn, panic-halting, planning-blackout), Coordinated Decisions, (Data/System)Ecology: Collapse & Productivity (default option: Agile, Kahneman-Tversky, Definition-Studies)
- process/policy areas may be seen as preventable-predictable-collapse-areas; each is an area of preventable mistakes that are not automatically self-preventing and that must be deliberately prevented. Problems that are not automatically visible or understandable can repeat indefinitely. Using process and policy can significantly help prevent and navigate recurring problems that are not automatically visible.
- not accounting for different workflows (e.g. frontend, backend, data-science, production machine-learning, R&D, test-reporting, etc.) will lead to delays and failures that should not have occurred. In the absence of communication and learning, these failures may be invisible and repeat indefinately because they are not seen and understood.
- Schedule: (Duration; Start date; Iteration Interval)
- timelines that need to be short but are never articulated or planned for are unlikely to usually spontaneously match the needed short scale planning needs.
- timelines that need to be long but are never articulated or planned for are unlikely to usually spontaneously match the needed long scale planning needs.
- undiscussed timelines risk being indeterminate, fickle, and unpredictably changing for no apparent reason, raising the liability of churn and repeatedly returning to square one.
- Users: Stakeholders & Needs & Goals Evaluation (of users)
- not having and coordinating with users/stakeholders and their needs significantly raises the probability that the project will not improbably spontaneously meet their unknown and possibly unarticulated needs by accident.
- not properly doing a needs and goals evaluation significantly raises the risk of goals being either incorrectly identified, or having goals indefinitely changing or rotating between amorphous unexamined but often entirely predictable areas.
- Features_Goals: User-Features & Subfeatures/Under-The-Hood Features including Categories of Types of Systems, Data-Types, Data-Structures, Structured Vs. Unstructured Data.(tech-stack and resources may be implicit for higher-level goals or explicit for resource-defined needs); lexicon: jargon vs. description;
- if you do not have a clear articulation of what you are doing (for a user/stakeholder to meet their clarified need) then it is unlikely that the possibly unknown goal will be accomplished in a maintainable way meeting the need of the user/stakeholder.
- MVP: 'MVP's (Minimum Viable Products); Deliverables Checklist; Tools, 'Tool Stack / Tech Stack',
- an MVP must not be an invocation of a reification-hallucination
- iteratively proceeding with transparency and feedback to align and fine-tune is appropriate and time-tested in many projects.
- articulating incremental MVP (minimum-viable-product) goals and stepping stones is an important part of progressing and communicating incrementally and/or progressing maintainably and sustainably.
- articulating incremental MVP (minimum-viable-product) goals and stepping stones is a skill in and of itself
- Feedback_Learning: Learning, Tests, Communication, Signals, Documentation & Iteration, Organizational, System, and 'Ecological' Effects, (~agile); Documenting-teaching-learning(skills); skills present, future (learning)
- whether formal or informal there must be effective ways of communicating what has been done within the project-team and between the project-team and the user/stakeholder.
- Failing to clearly map and communicate the differences between jargon terms and goal descriptions will result in mis-alignment between people and nonsense in planning.
- long term maintainability involves communication (including 'future you')
- learning directly and indirectly related to the specific project is necessary. If you do not learn that a user/stakeholder's need is not being met then long term failure is highly probable. If you continually learn and develop useful skills then long term successes are more probable.