"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 bearing in mind types of systems?
- Process (e.g. workflow type, policies, procedures)
- Schedules (e.g. starting, stopping)
- 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)
Defining Agile-Type Areas of Projects as a set of predictable recurring problems, such as can be checked for after each iteration of a project, and that evaluation used in future planning: I.e. Here are lists of known issues; Are any of these happening? If so, there are likely invisible problems that are entirely solvable on the level of process, communication, and (except for extremes) universally accessible skills and practices. The approach here is not to try to micro-manage a one-size fits all positive-definition that should apply to everything (all projects, teams, and workshops), but rather a negative-definition of problem-areas that every unique project in a unique situation in a unique place needs to (and can) figure out how to address.
Schedule-issues may be the most demonstrably relatable for any participants (if also not easy to communicate about smoothly even in extremely remedial ways). It may be helpful to think of a kind of 'schedule object permanence' in a kind of project-space-sally-anne test. Some people are skilled at perceiving and managing schedule-object permanence space, many people are not, but likely ~all people are able to learn basic schedule object permanence skills and have basic fitness. A key problem is that many people do not understand the possibility of there being a lack of schedule-object-perminance-space fitness (and other project areas), assuming that all world fitness is automatic. The concept of not-automatically-learned-skills, is itself not automatically learned.
- 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), for macro: Mapping/Modeling, Strategizing, Navigating, Decision-making, forming conclusions, planning, initiative-taking, leadership, etc.
- 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.
- standard, common, errors: laxity about and absence of schedule fitness will increase the likelihood of standard, common, entirely predictable basic schedule problems, including: -- sequence errors: putting first steps such as planning, brainstorming and early-drafts at or towards the end of the timeline, and putting end-steps first -- not scheduling planning time -- not using planning time -- not scheduling feedback and the use of feedback -- not using feedback-time or feedback -- brittle-schedule: not accounting for predictable delays -- best-case-scheduling: between a best-case, expected-case, and worst-cast schedule, only considering the best-case -- miscalculating durations -- ignoring scheduled timelines -- refusing to communicate about schedules -- trying to force planners and team-members to stop asking and talking about schedules -- having indeterminate schedule plans -- having simultaneous paradoxical schedules plans -- using nihilistic disinformation to discredit the value, function, and meaning of a schedule -- suddenly changing a schedule (or trying to), often at the last minute (such as the moment before everyone leaves a meeting) -- not having in-scope the possibility that the above violations of basic logic and common sense are possible and likely (in reality they are common (both possible and likely)). -- Classic inversion of planning & execution priories: A 'hurry up and wait' pattern where first you impatiently blitz to start a project without planning and then the policy flips 180 degrees so that no deadlines exist and people work indefinately on whatever whim of the moment.
-
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 design factors such as Categories of Types of Systems, Data-Types, Data-Structures, Structured Vs. Unstructured Data.(E.g. tech-stack and resources may be implicit for higher-level goals or explicit for resource-defined needs); lexicon: clarify jargon vs. description;
- From a user-story standpoint, what is this project making?
- From an Under-the-hood standpoint, what needs to be made and how for the project to be maintainable?
- Are these known? Do these need to be researched? -- 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. -- If you do not distinguish between and elucidate both user-story level features and sub-user-story level features (features/subfeatures) then quality, efficiency, and maintainability will be undermined.
- MVP: 'MVP's (Minimum Viable Products); Deliverables Checklist; Tools, 'Tool Stack / Tech Stack',
- Each 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. -- Without timely iterative MVP deliverables, feedback from the user about features and usability will be significantly hindered. -- Without data and feedback about initial MVP outcomes, blindness will strangle the management of the project, coordination of people, and the management of resources.
- Feedback_Learning: Learning, Tests, Communication, Signals, Error-Data (how are errors, mistakes, et al handled and used), Documentation & Iteration, Organizational, System, and 'Ecological' Effects, (~Agile); Documenting-teaching-learning(skills); present skills, future skills (learning) (Including routine checks such as "Is there anything to improve, do more of, do less of, start doing, or stop doing?")
- Based on what signals will you define failure and orient to measure productivity?
- 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.
- Long term maintainability involves communication (including with 'future you'). -- 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. -- The default patterns and processes of drift will misalign the team and user-stakeholders on many levels, making even detection of the misalignment a challenge. -- 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.
Managing general project areas as per the details and needs of each project (as described by that project's general project areas) is best practice for positive and sustainable aligned process and project outcomes.
- https://github.com/lineality/definition_behavior_studies
- https://github.com/lineality/Networked_Voting_and_Decisions_Including_One_Time_Pads
- https://github.com/lineality/needs_goals_assessment_disambiguation
- https://github.com/lineality/uma_productivity_collaboration_tool
- https://github.com/lineality/uma_productivity_collaboration_tool/blob/main/t_is_for_task.md
- Policy: Disable Auto-Pilot
- Needs & Goals Evaluation & Disambiguation
- Not Skipping Planning, Orientation & Navigation
- Incremental Movement with Review
- Preliminary-Start, 'Feature' scope evaluation, & a process to halt excessive scope/load (As John McCarthy noted in the 1950's about software targets 'easy things are hard.' It is often not possible to tell the work-scope/work-load of a feature unit preliminary work has been done. So, evaluation of the scope of a feature requires review of preliminary work.)