Огород

 Прикопал помидоры

Better Boy

BeafSteak

Project Management in The Hybrid Workplace

 Project Management in The Hybrid Workplace by Phil Simon 2022 Racket Publishing , 324 ps

Chapter 1

• As a group and for at least two decades, employees have never particularly felt engaged while on the clock. The reasons may stem from an especially pro-business environment in the United States.
• For decades, the business environment has been decidedly pro-business, especially in relation to other industrialized countries.
• COVID-19 caused the employer-employee pendulum to shift toward the latter. It won't be swinging back to the former anytime soon.
• Employees have spoken loud and clear: They want their work lives to revolve around their personal lives, not the other way around.

Chapter 2

• Elon Musk's audacious postpandemic behavior aside, certain types of work are much harder to pull off in remote and hybrid fashions.
• The process of navigating hybrid workplaces is especially tricky. Asymmetries abound, and proximity bias is a tough nut to crack.
• Thanks to massive advances in collaboration technologies and more relaxed views around remote work, employees can easily change jobs without uprooting their lives. The reduced friction in labor markets means more turnover, especially in today's high-inflation environment.

Chapter 3

• Minor changes throughout the supply chain reverberate throughout it. The bullwhip effect causes major problems that no company can resolve overnight.
• The process of managing physical inventory and natural resources is often just as vexing as managing people. 
• More efficiency means less resilience, and vice versa.
• Erring on the side of extreme efficiency makes any resource management system fragile.

Chapter 4

• Project management is a rich, vibrant, and multidimensional discipline.
• The type of methodology your team follows should reflect the project's ultimate goal. Don't try to fix a plane while it's in the air.
• Regardless of your approach on a given project, the tradeoff among cost, scope, quality, and time is real. If someone suggests otherwise, run.
• Historically, projects have failed about two times in five and that's when people largely worked in the same place at the same time.

Chapter 5

• Cognitive biases have always been problematic at work. They're even more vexing in hybrid and remote workplaces.
• The same delays that slow physical production lines slow human ones. The results are predictably similar.
• In their efforts to secure the enterprise, IT departments can complicate employees' efforts to communicate and collaborate, especially when working with outsiders.
• Employees have been working harder throughout the pandemic, but not necessarily smarter. Not surprisingly, they're exhausted. Something's gotta give.

Chapter 6

• Old standbys still matter, but it's imperative to add new questions when vetting prospective employees, vendors,
• clients, and partners for projects in hybrid workplaces.
• Consider the tools that a prospective partner uses to complete its projects. Generally speaking, the answer to that
• question will provide a valuable signal about whether you should walk down the aisle.
• Establishing core work hours can reduce employee stress, WIP, and turnover.

Chapter 7

• Millions of employees have accepted jobs during the pandemic. As a result, they have yet to meet their peers and have struggled to build valuable social capital with them.
• Through in-person meetings and project kickoffs, employees can build invaluable relationships and social capital. The benefits can be significant on complicated projects as problems manifest themselves.
• When getting together, think face up, not face down.

Chapter 8

• Employees use a greater array of tools than ever. Their willingness and ability to use those tools well-and possibly learn new ones-can determine if a project or product will
• succeed or fail.
• As soon as possible, talk tech with your would-be partners. Discuss and agree upon the tools that the team will use. And, for God's sake, involve IT early.
• Use a proper PM tool from the get-go. If you start a new project with a simple spreadsheet, it's unlikely that you'll
• think of everything you ultimately need from day one.
• For years, it's been dangerous to assume that another department within the same company uses the same tools-never mind an entirely different company altogether.

Chapter 9

• Conducting a project premortem reduces the chance that an organization will have to perform an autopsy down the road.
• An array of human biases prevents us from accurately assessing our ability to successfully plan and complete projects.
• Odds are that you'll face resistance when suggesting a project premortem, but the pros of doing one typically outweigh its cons.

Chapter 10

• Project and product pilots aren't novel ideas. In hybrid and remote workplaces, however, they're more important to conduct than ever.
• As Hertz's management learned the hard way, hiring a venerated consultancy doesn't guarantee a successful outcome-no matter which party was ultimately culpable for the $32-million disaster.
• Pilots can snuff out all sorts of project issues before a team or company gets in too deep. Potential problems may stem from employee skill levels, communication styles, partner compatibility, and logistics.

Chapter 11

• Even smart, successful people underestimate the value of employee training and the power of today's applications.
• The farther we are from our colleagues, partners, managers, and clients, the more we need to rely upon software programs and technology in general. That's why application training is so important.
• Expecting employees to learn on their own time and dime is sanguine at best and dangerous at worst.

Chapter 12

• Clear business writing has always been critical. The rise in hybrid and remote work only accentuated its importance.
• Amazon and Automattic are two prominent companies whose management has taken steps to institutionalize clear employee writing. More firms are coming around to the benefits of holding formal workshops.
• Workshops can pay off in spades, especially since electronic messages are becoming less disposable.

Chapter 13

• The advantages of MBWA may seem obvious, but the practice is pointless or even counterproductive in remote and hybrid workplaces.
• A construction company used analytics to turn around a failing project.
• Even the most sophisticated use of analytics guarantees nothing. Analytics can, however, help people make more informed project- and product-related decisions.

Chapter 14

• In-person performance management has always proven challenging. It's even harder in hybrid and remote workplaces.
• Taken together, proper PM and survey tools can help diagnose project issues and identify ways to correct them.
• Organizations are beginning to creatively reward their employees with nontraditional employee benefits and bonuses. These can improve employee morale, reduce attrition, and potentially mitigate project-related issues.

approx. 12.5 h June July 2025

9 дней...

Кошка Мийка, продолжение

Тяжело видеть как исчезает в небытии память - запахи, вес на руках, прикосновение шерсти. Постираны и убраны тряпочки (войлочные подстилки), непромокаемое покрывало с дивана, выброшены ставшие ненужными флакончики с остатками антибиотиков, рецепт мази для Mia, Shchelokova...

Кошка Мийка

Кошка Мийка умерла. В ветеринарном госпитале должны были сегодня сделать эвтаназию. Чуда не произошло. 28 декабря 2021 - 28 сентября 2022.

Rapid development: Taming wild software schedules

Rapid development: Taming wild software schedules
Steve McConnel
Microsoft Press, 1996
ISBN: 1-55615-900-5

Despite possible expectation this book is not about software tools and technologies but about project managemet.

Part 1 Efficient Development

1. Welcome to rapid development

2. Rapid-development strategy

3. Classic mistakes

4. Sodtware-Development fundamentals

5. Risk management

Part 2 Rapid development

6. Core issues in rapid development

7. Lifecycle planning

8. Estimation

9. Scheduling

10. Customer oriented development

11. Motivation

12. Teamwork

13. Team structure

14. Feature-Set control

15. Productivity tools

16. Project recovery

Part 3 Best Practices

17. Change board

18. Daily build and smoke test

19. Designing for change

20. Evolutionary delivery

21. Evolutionary prototyping

22. Goal settings

23. Inspections

24. Joint Application Development (JAD)

25. Lifecycle Model Selection

26. Measurement

27. Miniature milestones

28. Outsourcing

29. Principled negotiations

30. Productivity environments

31. Rapid-development languages (RDL)

32. Requirements scrubbing

33. Reuse

34. Signing up

35. Spiral lifecycle model

36. Staged delivery

37. Theory-W management

38. Throwaway prototyping

39. Timebox development

40. Tools group

41. Top-10 risks list

42. User-interface prototyping

43. Voluntary overtime

Read on Jun. 10  - Aug. 20, 2022, approx 27 hours

Making Things Happen

Scott Berkun
Making Things Happen
O'Reilly 2008
ISBN: 9780596517717

Chapter 1. A brief history of project management

• Project management is everywhere, and it's been around for a long time. 
• If you keep a beginner's mind, you'll have more opportunities to learn.
• Project management can be a job, a role, or an activity.
• Leadership and management require an understanding of, and intuition for, several common paradoxes. These include ego/no-ego, autocracy/delegation, and courage/fear.
• Watch out for pretension and over-involvement in your management activity. The process should support the team, not the other way around. 
• If you are a dedicated manager, look for ways to capitalize on your unique perspective of the team and project. 

Chapter 2. The truth about schedules

• Schedules serve three functions: allowing for commitments to be made, encouraging everyone to see her work as a contribution to a whole, and enabling the tracking of progress. Even when schedules slip, they still have value.
• Big schedules should be divided into small schedules to minimize risks and increase the frequency of adjustments.
• All estimates are probabilities. Because schedules are a collection of estimates, they are also probabilities. This works against schedule accuracy because probabilities accumulate (80%×80% = 64%).
• The earlier that estimates are made, the less accurate they are. However, rough estimates are the only way to provide a starting point for better ones. 
• Schedules should be made with skepticism, not optimism. Invest in design to shed light on assumptions and generate reliable confidence.

Chapter 3. How to figure out what to do

• Different projects demand different approaches to planning.
• How planning is done is often determined by who has what authority. Requirements, design, and budget are the three kinds of project authority that impact planning.
• There are some common deliverables for planning projects: marketing requirements documents (MRDs), vision/scope documents, specifications, and work breakdown structures (WBSs).
• The most powerful way to plan a project involves use of three equal perspectives: business, technology, and customer. The customer perspective is often the most misunderstood and misused.
• Asking questions forces good thinking and directs planning energy effectively.
• The process of defining requirements is difficult, but there are good references for how to do it well.
• Problem statements and scenarios are a simple way to define and communicate requirements. They are easily converted into design ideas without losing clarity about what's important and what isn't.

Chapter 4. Writing the good vision

• Vision documents distill other planning materials into a single, high-level plan.
• Writing things down serves the author and the team. It provides the basis for discussion and a point of reference that doesn't rely on our fallible memories.
• The amount of detail in your vision document varies with the nature of the team and the project.
• Team goals should derive from goals defined in the vision. Individual goals should derive from the team goals.
• Good visions are simple, goal-driven, consolidated, inspirational, and memorable.
• Volume does not equal quality. It takes more effort to be concise than not. 
• Keep the vision alive by asking questions about the utility of the vision to daily decisions on the project.

Chapter 5. Where ideas come from

• Many teams don't properly manage the time between requirements and specifications.
• Quality requirements and design explorations are the best use of that time. Ideas are good or bad only in relation to goals or other ideas.
• Constraints are useful in finding ideas, but thinking outside the box isn't necessarily the answer. Sometimes the best solution is finding a clever way to work within the constraints.
• Questions, perspectives, and improvisational games are tools for finding new ideas.
• The best place to start with design ideas is the customer experience.
• Ideas develop into designs through conversations between different people with different kinds of expertise.

Chapter 6. What to do with ideas once you have them

• Ideas have their own momentum. It will take longer to rein in creative work than you expect. Changes will cascade through a project.
• Create checkpoints for creative work to track and manage it. Common checkpoints include proof-of-concept, idea groupings, three alternatives, two alternatives, and one design.
• Use affinity diagrams to consolidate ideas.
• Prototypes enable the project to confront issues early and learn from mistakes without significant risk.
• Use iterations, or the periodic refinement of a prototype, to ask questions, evaluate progress, and decide on the next steps.
• Create an open-issues list to track questions that need to be resolved before specifications can be completed.

Chapter 7. Writing good specifications

• Specs should do three things: ensure that the right product gets built, provide a schedule milestone that concludes a planning phase of a project, and enable deep review and feedback from different individuals over the course of the project.
• Specs solve only certain problems. Team leaders should be clear on what problems they are trying to solve with specs, and what problems need to be solved through other means.
• Good specs simplify. They are primarily a form of communication. Specifying is very different from designing.
• There should be clear authority for who writes and has control over the spec.
• Closing the gap is one approach to managing open issues and to accelerate the end of the specification process.
• A review process is the simplest way to define and control spec quality.

Chapter 8. How to make good decisions

• There is an important skill in meta-decision making, or decisions about which decisions to invest time in.
• Size up decisions before spending too much time on them.
• Look for the zone of indifference and opportunities for effective use of singular evaluation.
• Use comparative evaluation for the decisions worthy of more investment. All decisions have emotional components to them whether we admit it or not.
• Pros and cons lists are the most flexible method for comparative evaluation. They make it easy to involve others and get additional perspectives on decisions.
• Information and data do not make decisions for you.
• You improve at decision making by reviewing past decisions and exploring them for lessons and opportunities for better tactics.

Chapter 9. Communication and relationships

• Projects happen only through communication. In modern times, speed isn't the communication bottleneck, quality is.
• Relationships enhance and accelerate communication.
• There are several frameworks for how people communicate with each other. PMs should be familiar with them so that they can diagnose and resolve communication breakdowns.
• There are several common communication problems, including assumptions, lack of clarity, not listening, dictation, personal attacks, and blame.
• Role definition is the easiest way to improve relationships.
• Ask people what they need in order to do their best work. Ways to do this include: listening, clearing roadblocks, teaching, and reminding them of goals.
• Relationships and communication are not low-priority work. They are essential to all of the individual activities that take place during a project.

Chapter 10. How not to annoy people: process, email, and meetings

• Project managers are prone to annoying others. Some of it is avoidable. People get annoyed for many reasons. Often, it's when they feel their time is wasted, when they are treated like idiots, or when they are expected to endure prolonged tedium and mistreatment.
• Good processes have many positive effects, including accelerating progress and preventing problems. But, they are difficult to design well. Non-annoying email is concise and actionable, and it quickly allows readers to determine whether they are impacted enough to need to read more than the subject line or first sentence.
• Meetings run well when someone facilitates them.
• Frustrating meetings occur when the goals are mismatched to the type of meeting.

Chapter 11. What to do when things go wrong

• No matter what you do, things will go wrong.
• If you can stay calm and break problems down into pieces, you can handle many difficult situations. (Remember the rough guide.)
• There are some common situations to expect, which include oversights, being forced to do stupid things, resource shortages, low quality, direction changes, personnel issues, and threats of mutiny.
• Difficult times are learning opportunities. Make sure you and your team take the time to examine what happened and how it could have been avoided.
• Taking responsibility for situations, regardless of who caused them, always helps to expedite resolving the problem.
• In extreme situations, go into damage-control mode. Do whatever it takes to get the project to a known and stable state.
• Negotiation is useful not only in a crisis situation, but also in management. Good negotiators work from people's interests, not their positions.
• Have clear lines of authority at all times. People should know who has decision-making power before a crisis occurs.
• People respond to pressure in different ways. Be observant and open in how you help the team deal with the different kinds of pressure.

Chapter 12. Why leadership is based on trust

• Trust is built through effective commitments.
• Trust is lost through inconsistent behavior on matters of importance.
• Use the granting of authority and trust to enable people to do great work. Granted power comes from the organizational hierarchy. Earned power comes only from people's responses to your actions. Earned power is more useful than granted power, although both are necessary.
• Use delegation to build trust on your team and to ensure your team against adversity.
• Respond to problems in a way that will maintain people's trust. Support them during crises so that they bring issues to you instead of hiding them. Trust in yourself is the core of leadership. Self-discovery is the way to learn who you are and to develop healthy selfreliance.

Chapter 13. Making things happen

• Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.
• The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal. There is a bright yellow line between priority 1 work and everything else. Things happen when you say no. If you can't say no, you effectively have no priorities.
• The PM has to keep the team honest and close to reality.
• Knowing the critical path in engineering and team processes enables efficiency.
• You must be both relentless and savvy to make things happen.

Chapter 14. Middle-game strategy

• Mid-game and end-game correspond to the middle and end of the project. If on any day the project is not going well, it's your job to figure out what's wrong and resolve it. Repeat this throughout mid-game.
• Projects are complex nonlinear systems and have significant inertia. If you wait to see acute problems before taking action, you will be too late and may make things worse.
• When your project is out of control, you are flying behind the plane, which is a bad place to be. Sanity checking is the easiest way to stay in front of the plane. There are both tactical and strategic sanity checks.
• Consider how to take action to correct a situation in the safest way possible. The larger the action, and the further along the project is, the more dangerous the actions are.
• The coding pipeline is how work items are managed during implementation. There are aggressive and conservative ways to manage the pipeline.
• Milestone-based planning and the coding pipeline provide opportunities to make safe course corrections for projects.
• Change control (DCRs) is how you throttle the rate of medium-and low- level change on a project.

Chapter 15. End-game strategy

• Big deadlines are a series of small deadlines.
• Any milestone has three smaller deadlines: design complete (specs finished), feature complete (implementation finished), and milestone complete (quality assurance and refinement finished).
• Defining exit criteria at the beginning of milestones improves the team's ability to hit its dates.
• Hitting dates is like landing airplanes: you need a long, slow approach. And you want to be ready to take off again quickly, without having to do major repairs.
• You need elements of measurement to track the project. Common elements include daily builds, bug management, and the activity chart.
• You need elements of control to project level adjustments. Common elements of control include review meetings, triage, and war team.
• The end of end-game is a slow, mind-numbing process. The challenge is to narrow the scope of changes until a satisfactory release remains.
• Now is the time to start the postmortem process. Give yourself and your team the benefit of learning from what went well and what didn't.
• If fortune shines on you, and your project makes it out the door, be happy. Very, very happy. Many people, through no fault of their own, never get that far. Plan a grand night. Do ridiculously fun and extravagant things (including inviting this author to the party). Give yourself stories to tell for years to come.

Chapter 16. Power and politics

• Politics are a natural consequence of human nature. When people work together in groups, there is a limited amount of authority, which must be distributed across different people with different desires and motivations. All leaders have political constraints. Every executive, CEO, or president has peers or superiors who limit their ability to make decisions. In general, the more power a person has, the more complex the constraints are that they must work within.
• There are many different kinds of political power, including rewards, coercion, knowledge, referent, and influence.
• Power is misused when it's applied in ways that do not serve the project goals. A lack of clarity around goals, unclear resource allocation or decision-making processes, or misunderstandings can contribute to the misuse of power.
• To solve political problems, clarify what you need. Identify who has it, and then assess how you might be able to get it.
• If you are involved in project management, you are defining a political playing field around you. It's up to you to decide how fair or insane it is.

Read on Jan. 26  - Mar. 20, 2022, approx 25 hours