Influencer Courses

Influencer courses are specifically design for project managers, business analysts, Scrum masters/owners and other software executives to influence project sponsors, team mates, and people within the project ecosystem.  The course is accomplished in 4-steps. 

• Step 1: Watch the Influencer video;
• Step 2: Read the guide and book
• Step 3: Complete on-line the organizational appraisal; 
• Step 4: Discuss the results of the appraisal report with your mentor. 

The idea of the course is to will help you measure your organizational skills and abilities against the Standish yardstick. Once completed, the appraisal system will generate a score and provide a 5-page benchmark report for you against other organizations. The course will help you understand the principles and skills to advise people on their role. Each step will take about an hour, 10-hour observation period and a ten-minute conversation with your mentor, except for step 4 which the mentor discuss will be 30-minutes. The benefits of the Influencer Courseare: 

• Understanding the principles and skills 
• How to influence the people on projects 
• Three suggestions for maximize improvement
• How to sell the course internally

The Influencer course will take a minimum of 1 hour per day over 4 days (estimated 5 hours). 

Crash Courses

Crash Courses are designed to improve the skills of people in projects. The courses are a rapid structured program managed by a professional mentor/professor. This mentored workout is optimized to present the most important material in the shortest amount of time. The workout is accomplished in 12-lessons at your pace.  Each of the 12 lessons is accomplished in 3-steps

• Step 1: One-hour lesson;
• Step 2: 10-hour observation period, feedback;
• Step 3: 15-minute conversation with your mentor. 

Each of the 12-one hour lessons, starts with a microblog, 10-minute video, book chapter, 

The idea of the course is to will help you measure your skills and abilities against the Standish yardstick. Once completed, the appraisal system will generate a score and provide a 5-page benchmark report for you against other people or organizations. The first and last lesson includes the appraisal and benchmark. The course will help you understand the principles and skills of being a good sponsor, team mate or the ecosystem and how you stack up. The benefits of the Crash Courseare: 

• Increase project success and reduced failures
• 3 suggestions for maximize your improvement
• Constant skills improvement
• Understanding the principles and skills

The course will take a minimum of 1 hour and half per day over 12 days (estimated 20 hours).

Mentor Courses

Mentor Courses are designed for the mentor to mentor sponsors, team mates and other professionals. The Mentor Courses can also improve the skills of the project sponsor, team mates and other professionals.  Mentor Courses can also be used for higher educational credits. These courses are perfect for PMO executives. The courses are a slow-paced structured program managed by a professional mentor/professor. These courses are optimized for retention. The course is accomplished in 12-lessons 7-part nanolessons at your pace.  Each of the first 6 nanolessons is accomplished in 4-steps

• Step 1: 20-minute lesson;
• Step 2: 10-hour observation period;
• Step 3: 25-word feedback
• Step 4: Mentor approval 

On the 7^thnanolesson you will have a 10 to 15-minute conversation with your mentor and write a microblog of 100 to 200 words on what you have learned. The microblog must be approved by your mentor. This course is basic requirement to be a Standish mentor, but as a potential mentor you must have experience in the field on software projects.  The course for graduate students is for educational credit and expanded knowledge.  The first and last lessons includes the appraisal and benchmark. The course for the sponsor provides in-depth understandings of the principles and skills of a good sponsor and how you stack up. The benefits of a Mentor Coursefor a sponsor are:

• Acquisition of good habits
• High retention of project skills
• Life-Long Learning Credits
• Confidence in your ability to manage projects

The courses will take a minimum of half hour per day over 84 days (estimated 50 hours).

Go to our storeto see currently available courses. 

·       Simple Dezider

• ·       Current CHAOS reports (2016 to 2020)
• ·       Selected special research reports
• ·       Environmental assessments
• ·       Optimix for Portfolio of Projects
• ·       EZ-Optimix for Single Project (unlimited features)
• ·       Drafts of Work in Process research
• ·       All the services of the free membership

To join the premium membership, go to: 

https://www.standishgroup.com/store/.

Please note that dezider.com will go offline forever on August 31, 2019.

If you have any questions, please contact Jennifer Lynch at Jennifer@standishgroup.com.

• ·       Current CHAOS reports (2016 to 2020)
• ·       Selected special research reports
• ·       Environmental assessments
• ·       Simple Dezider
• ·       Optimix for Portfolio of Projects
• ·       EZ-Optimix for Single Project (unlimited features)
• ·       Drafts of Work in Process research
• ·       All the services in the basic membership 

To join as a premium member, go to: 

https://www.standishgroup.com/store/.

If you have any questions, please contact Jennifer Lynch at Jennifer@standishgroup.com.

• ·       Café CHAOS blog posts
• ·       CHAOS Tuesday podcasts
• ·       Advice (formally pm2go content)
• ·       Legacy CHAOS reports (1994 to 2015)
• ·       General research reports
• ·       EZ-ROI 
• ·       EZ-Optimix for Single Project (limited features)

To join, please go to:

https://www.standishgroup.com/registration/registration/registration.

Please note that blog.standishgroup.com (Café CHAOS) will go offline forever on August 31, 2019.

• ·       Café CHAOS blog posts
• ·       CHAOS Tuesday podcasts
• ·       Advice (formally pm2go content)
• ·       Legacy CHAOS reports (1994 to 2015)
• ·       General research reports
• ·       EZ-ROI 
• ·       EZ-Optimix for Single Project (limited features)

To join, please go to:

https://www.standishgroup.com/registration/registration/registration.

Please note that blog.standishgroup.com (Café CHAOS) will go offline forever on August 31, 2019.

The Flow process creates pipelines segmented by very small logical and cross-functional teams.  Work is created in daily tasks and distributed through a priority-based algorithm without bias.  All daily tasks are implemented either at the end of the day or of the next day. This increases user absorption and reduces training events and implementation delays. Flow also reduces technical debt by a continuous refactoring in order to keep software fresh and usable, thus reducing the high cost of maintenance.

Flow incorporates the features and functions of agile/Scrum, DevOps, Normalized Systems, DEMO, and microservices. Flow can sit on top of current applications or new minimal viable products. Flow pipelines represent a single budget item and thus eliminate the high overhead cost associated with traditional project and change management. 

The Flow structure is broken down into flow sponsors and two major distinct groups: producers and actors. Each sponsor supports teams of producers and actors.  This support can be either stable or dynamic.  In a stable condition, the producers and actors are tied directly to the sponsor.  In a dynamic condition, the producers and actors float between sponsors as work objectives change.  The sponsor provides inspiration, direction, and imagination and is ultimately responsible for the work product of the two teams. (The skills needed to be a good sponsor are outlined in our guide and appraisal, The Good Sponsor.)  

Producers define the work, manage the backlog, and present activities to actors. Producers are a combination of former project managers, business analysts, Scrum product owners, and subject matter experts. Producers generally work in teams of two to four people. Their main job is to break down the work into daily microservices that actors can complete in one day.  (They often use DEMO for rapid design and thinking.) Actors perform and implement the work the producers give them—work that is expected to be completed within one day. Actors are generally developers, installers, and experts in quality assurance, security, and computer operations. Each team of actors comprises three or four people, often using Normalized Systems.  Both producers and actors work in self-directed teams. (The skills needed to be a good teammate are outlined in our guide and appraisal, The Good Mate.)

As we see it, there are only three factors involved in success: a good sponsor, a good team, and a good place in which to work.  There are 10 principles and 50 skills involved in being a good sponsor and a good mate. We are working on a similar guide and framework for a “good place” and are centering it around the principles and skills necessary for a successful Flow process. 

Project managers will always have a place, but maybe not in the development of software. This is a problem I have been thinking about and struggling with over the last few years, and it got me thinking about the history of software development and how project management fits into a historical time line. I have come up with four distinct evolutionary periods. The first period I call the Wild West, which ran from around 1960 to about 1980. The Waterfall Period ran from 1980 to about the year 2000. The Agile Period started around the year 2000, and my prediction is it will end around 2020. We are now seeing the beginning of what I’ll call the Flow Period, which will start in earnest around 2020. My crystal ball does not go past 2020, but I imagine it will last at least 20 years.

The Wild West Period – During this period, I was actually writing code and creating software. I was the business analyst and the project manager—even though I was not called a project manager. I wrote the requirements, the engineering specifications, and the actual machine code. I compiled it and created the test suites (both unit and system), the user documentation, and the user training. And finally, I maintained it. However, most of the software was used to automate basic management functions, such as payroll and accounting. During this period, there were very few project managers. If there was a project manager, he or she generally came up the ranks of the software development community. For the vast majority of business people, software was a complete mystery, and the general population considered it to be magic. 

The Waterfall Period – This era ran strong from 1980 until the year 2000. The infamous “dotcom bubble,” from ’95 to ’01, catapulted software development into the stratosphere. Software projects grew larger and much more complex. Many of them became mission-critical, fulfilling orders and building products. As the need for computer services grew, so did the need for more job specialization. Quality assurance became a department. Creating requirements and specifications became a discrete skill. It was clear that projects needed a higher degree of management oversight, adding major cost to the projects. IT management looked to the construction industry to see how it managed creating both skyscrapers and normal housing. Projects were broken down into phases like a waterfall and were documented by a plan. Late in this period, IT management thought that almost every project should have a professional, certified project manager. The result was a steep rise in the job market for that profession. 

The Agile Period – When it became clear that the waterfall structured approach, with high overhead costs and long delivery times, was not producing improved results and value, the Agile Period began. Projects were broken down into smaller and smaller deliverables, which produced increased success rates, greater value, and higher-quality software. Teams became self-directed, product owners became closer to the teams, and rapid delivery of products ruled the day. Scrum became the King of Agile, with the project management duties falling to the product owner and Scrum master. Project managers tried in vain to find a place to add value to the agile process. The Project Management Institute created an agile project management certificate, but those duties were really about tracking deliverables and accounting. Advances in technology, such as tools to create and manage small projects (now known as microservices), further reduced the role of the project manager. Scrum was also integrated into DevOps to create a seamless delivery between software development, implementation, and services delivered via the software pipeline. 

The Flow Period – A renaissance of the Wild West should begin in earnest around 2020 and will be marked by the development of software in a continuous process pipeline.  What Scrum was to agile, DevOps is to Flow.  In the Flow Period, there will be no project budgets, project plans, project managers, or Scrum masters. There will be a budget for the pipeline, which is a pure direct cost of the output. There will also be a cost to manage the pipeline, which will reduce the current project overhead cost by as much as 90%. This is done by reducing and eliminating most of the current project management activities. Work will come into the pipeline and out of the pipeline fully usable. Change will happen continuously, but in small increments that will keep everything current, useful, and more acceptable to users. 

There is an old joke by the comic Steven Wright that I often quote during my talks. The joke goes like this: “If your parents didn’t have children, then chances are you won't either.” The joke is funny but true, and it applies to projects. If you do not have projects, you will not have any failed or challenged projects. You will not have to estimate the cost of the project. You will not have a project manager assigned to the project. You will not have conflicts over budgets. This, of course, does not mean waterfall projects will go away by 2020. Also, agile projects will be around for a long time. The Wild West will continue to be the Wild West. However, we will see organizations move from project-based software development to a pipeline over the next 20 years or more.

What this does mean is that we will have a whole new cast of people to feed, manage, and produce that pipeline.  We will further define Flow and look at what kinds of skills, people and principles will be needed to manage software flow in a future writings.

As the new general manager for the Asian territory of the Sword Elevator company, Christina Yip was very concerned about the high level of accidents, and even fatalities, in the maintenance workforce for her area.  Yip felt it was her responsibility to understand the causes of the problem and thereby find a solution. She immediately set out to visit the maintenance managers and the field force to see for herself.  What she learned almost immediately was that as a result of retirement, turnover, and the combination and breadth of older and newer systems, the capabilities of the current workforce were at an all-time low. Training for new workers was intense, certainly—but it mostly focused on the newer systems.  However, Yip’s territory contained mostly older elevators, and many of those came from prior company mergers.  

Yip hosted a series of workshops and brainstorming sessions with a cross-section of her executive team and mid-level managers, including some from IT and other groups.  These exercises highlighted one obstacle after another. Her next move was to join an executive group of similar organizations in the same territory.  She quickly learned that, as a group, they faced similar obstacles, and went about learning some of their solutions. Yip went to work solving many of the easier issues right away, but she was still stymied by the lack of institutional repair knowledge at Sword. The company certainly had some maintenance people who knew how to repair virtually every type and model. However, in many cases, that boiled down to one person—in a vast territory. 

Yip dreamed big. Among her imaginings was the drastic empowerment and safety improvement that might be attained with the use of the Internet of Things. What if the field team could be coached remotely by Sword’s most knowledgeable maintenance people via an augmented reality system? Yip shared her idea with Patricia Lee, Sword’s VP of modernization.  Lee agreed to head up a project involving a voice-controlled head-mounted wearable computer, but she needed to modify some software to adapt to Sword’s field use and back-end systems.   Meanwhile, Yip presented her case to Sword’s CEO—who saw the value in this project and agreed to a swift initiation of a pilot project.  Yip chose the Bangkok region to run the pilot, since that area included most of the elevator types in use, as well as the most knowledgeable maintenance force. 

Lee quickly put together a “Hot Team” under a POC (Proof of Concept), with a vendor committed to deliver within a six-week period. At the end of the six weeks they found, as a group, that their pilot passed all of the fairly-strict POC requirements. The team was elated.  Yip went ahead and presented their findings to the company’s board, asking for—and receiving—full funding to roll out the new hands-free remote mentoring and document control system to the entire Asian region.  In one year, Yip’s initiative reduced safety issues by 30% and increased field productivity by 48%. The project also drastically improved the morale of Sword’s field workers.  Now, the board is considering taking Christina Yip’s program worldwide.

Loonshots: How to Nurture the Crazy Ideas That Win Wars, Cure Diseases, and Transform Industries by Safi Bahcall. I like this book and give it 5 out of 5 butterflies. It is written well, and complex ideas are presented simply. Of course, one of the reasons I like the book is that Bahcall agrees with my premise that there is no such thing as disruptive technology (see my comments in the Café CHAOS Blog post “Disruptive Technology is Disturbing”). However, the major takeaway from the book is this: what you need to successfully pull off a loonshot is a good environment, a good sponsor, and a good team.

But wait: What is a loonshot? Bahcall describes it as “a neglected project, widely dismissed, its champion written off as unhinged.” And what is a good environment for a loonshot? Bahcall suggest that loonshots are most likely to succeed when they’re championed by small teams that create flow.  Really, this is similar to the project environmental concept we outline in our current CHAOS Report and project environmental benchmark. Benchmarking your project environment provides insight into how well each aspect of that environment is performing, allowing you to discover what areas need improvement while helping you to develop a plan towards achieving those improvements. (You can get the latest CHAOS Report: Decision Latency Theory (2018) package in our store.)

As a perfect model of a project sponsor, Bahcall introduces Vannevar Bush, who created and ran the US Office of Scientific Research and Development (OSRD) during World War II. OSRD was the prime organization for the development of radar—which was a major contributor to winning the war. For our part, at Standish Group, we have spent the past 25 years exploring the skills and habits of successful project sponsors—or what Bahcall calls “champions.” In our book and associated benchmark, The Good Sponsor, we lay out 10 principles and 50 skills you need to be a good project sponsor or champion. (You can get the book in our store. You can even get a mentored class on how to be a good project sponsor and develop good sponsor habits.) 

And how does Bahcall describe a good team? He likes to use the analogy of ice-to-water and water-to-ice to demonstrate what he calls “phase transitions.” Keeping teams on the edge of the phase, Bahcall believes, provides dynamic equilibrium.  From our research, we suggest that most successful teams are made up of emotionally mature individuals. In fact, we wrote a book (and a benchmark) called The Good Mate, which lays out 10 principles and 50 skills you need to be a good emotionally mature teammate. You can also find this book and benchmark in our store store. 

Once upon a time, the principal of an elementary school, Joan Fanning, was daydreaming about how she could help her students learn more and have more fun along the way. Her husband, the Scrum Master for a software development firm, had explained the Scrum method to her, and they both thought it could be useful for her students.  He introduced her to a local Scrum trainer, and they talked about what kind of time and resources she would need to implement Scrum. Her husband also brought her around to other organizations, including some non-profits, that had implemented Scrum successfully. Fanning decided to implement Scrum in her school and in every classroom.  She called her program “Scrum4Kids.”

Fanning brought her teachers together and laid out a vision of how they would implement Scrum in the school. All of the teachers would need to take a two-day class with a certified Scrum trainer to learn the Scrum method and the Agile process.  Not all of them were happy with this decision, but Fanning was able to gain consensus and set expectations on changes going forward. (She also wanted to make sure that none of the teachers would sabotage the program before it got started. The fact that they could use the Scrum training as part of their continuous education credits was a plus.) In the end, Fanning inspired one of the teachers, Ann Jones, to be the first to try this new approach; hers would be the pilot Scrum4Kids program.  The assistant principal, John White, volunteered to be Jones’s “product owner and keep track of the work backlog. Fanning had enough money in her budget to send Jones and White to Scrum Master training and to send White to a Scrum product owner class. 

A few weeks later, Fanning and White sat in the back of Jones’s classroom and watched the teacher present to her class a “Little Scrum Board” that featured three columns headed “Tasks To Do,” “Doing Tasks,” and “Tasks Done.” Jones proceeded to explain, in simple terms, this new and inspiring self-directed methodology.  She asked the children to list tasks that they normally did every day—at home and in school—on sticky notes.  She showed the children some examples of how these lists might look. The class would do their tasks daily, updating the Scrum board and creating new tasks from a backlog created by White. 

After two weeks, Jones’s class had completed their first “sprint” and were ready for their first retrospective. Principal Fanning wanted to be part of this retrospective, and White, as well as some of the other teachers, also wanted to join in. (One of these teachers was Mr. Walker, who at every opportunity had criticized the Scrum4Kids program and made light of their efforts. He hoped to sabotage the project) In any event, the retrospective went well and resulted in many improvements to the class functions.

For the next three months, Jones ran two-week sprints.  Every morning the students would stand up and say what they had done yesterday, what they planned to do that day, and if they were having any problems with their tasks. Once a day, Principal Fanning would walk by the Scrum board and review it.  At the start of every two weeks, Jones and White held a sprint planning meeting.  At the end of every two weeks, they held a retrospective.  Sometimes Fanning would join them. 

At the end of the three months, Fanning invited her peers from other schools to do an assessment of the program.  They found that, as a group, the students in the Scrum4Kids program had twice the material adoption and greater retention than other, similar classes.  They also seemed much happier and displayed fewer behavioral problems. Fanning presented her findings to the School Board. She asked for, and received, funding to roll out Scrum4Kids to the rest of the elementary school.  This funding included Scrum training for the other teachers and additional training for more Scrum product owners. Mr. Walker transferred to another school—with the help of Principal Fanning, who then Scrummed happily ever after. 

Note: David Johnson completed a 12-week Standish Nanoclass on how to be a good project or executive sponsor. For information on Good Sponsor Classes, visit our store.

Electronic Health Records (EHRs) were described as a way to make medicine better, faster, cheaper, and safer. However, an April 2019 article in Fortune, “Death by A Thousand Clicks”by Fred Schulte and Erika Fry have raised serious questions. Ten years and $36 billion later, the system is an unholy mess. Although the article does mention some positive outcomes of EHRs, the focus is to warn of the harmful results.

First, physician satisfaction is important, because physicians will be the system users.it seems that in order to design an EHR system that could be utilized by all physician and for all possible situations, the program designers created elaborate systems that required several steps and clicks of the computer to find relatively simple concepts which made relatively simple things frustrating and impossible.

EHRs could be a way of institutionalizing the best approach to various diseases taken by the best physicians in the world. Taken to another extreme, computers could learn how to diagnose diseases without the need, in theory, of a physician. This is already happening; and anyone with a little experience can diagnose themselves with google or YouTube.  Soon, Apps will be built, where people will be able to diagnose themselves more reliably than doctors. The value of a physician is intelligence, and what is more intelligent than a computer.  Currently, the physician’s experience is better and more reliable than a machine, but this is changing quickly.  This doesn’t mean that we will completely eliminate the need for doctors, but it does mean that medicine will integrate technology that augments the way medicine is practiced.

Second, Physicians have to cognitively switch between focusing on the record and focusing on the patient. The physician is requested to move from writing in pen to [entering a computer] record, and it’s pretty complicated interface. 

Third, the patient is concerned with two main issues: privacy and outcome.  Are the EHRs secure and will they lead to better outcomes at a reduced price?  The privacy issue is compromised by the different motivations of the manufactures, hospitals, and patients. The information in the medical file is personal to the patient and any breach of the file is potentially harmful. If the file is compromised it is only inconvenient or embarrassing to the software manufacturer or hospital; but it is tragic to the patient.

The U.S. government push for EHRs.

·      EHRs is what the government mandated,

·      Vendors had to develop systems that met the government’s requirements. What are these government requirements and were physicians involved to develop the functional specifications?

·      The need to stimulate the economy (the industry’s race to market took priority over all else).

Large public multimillion funded software projects fail consistently for two reasons:

1.   The project is too ambitious,

2.   The project is too complex.

Lessons learned; develop a realistic plan in terms of budget, time and target and don’t pay in full a software developer before the product meets the functional requirements. 

Jan Poort is a seasoned high-level global IT executive. Jan has well-rounded skills in general management, software development, IT operations, sales and marketing. He has worked in Europe for such powerhouses as Unisys, HP, Digital Equipment, Minihouse and Philips Data Systems.

The Byzantine Empire was a world power between 324 and 1453 AD and at times included North Africa, Italy, and Rome itself. During this time the Empire was ruled by nearly one hundred emperors. It also waged dozens of wars and hundreds of battles, which required, naturally, thousands of generals. During battle campaigns, the Empire's generals needed to coordinate their attacks—and this mainly depended on outriders, since of course there was no other way for battle leaders to communicate. How could they agree on whether to attack or retreat? And what if some of them disagreed or were actual traitors to the emperor? This dilemma became known as the Byzantine Generals’ Problem and—thousands of years later—led to a protocol in distributed computing known as the Byzantine Agreement Protocol (Byzantine General's Algorithm). In his book Connections,James Burke chronicles how one invention builds onto another—leading to even more inventions. Technology does not spring out of the ground; it is a process, and sometimes a long process. 

Almost 99% of current pitches to venture capitalists include the phrase “disruptive technology.” The common definition of this phrase is “technology that disrupts the marketplace and replaces the current offering.”  Uber, for instance, is often described as a disruptive technology. However, consider that Uber’s technology is basically a cell-phone app. When Uber started, there were already a million apps for mobile phones. This means that all of Uber’s technology was in place before Uber came along. What Uber actually disrupted was the long-standing idea of a taxi marketplace, and it did so through the clever use of an advanced—but common—technology. 

What, then, is the difference between “disruptive technology” and “technological advancement”? Consider another example. The iPhone had a major effect on the cell phone market (and is also often cited as disruptive technology). Prior to the iPhone, I had a Motorola Razr that fit very nicely in the change pocket of my Wrangler jeans. I also had an iPod and a PalmPilot. I used the iPod to listen to books and never used the PalmPilot. I now use my iPhone to make calls, listen to Audible, get my e-mail, and summon Uber.  Steve Jobs integrated commonly available parts coupled with advanced software development to create the iPhone. 

If ever there was a pure disruptive technology, it would be the Segway. In 2001, Steve Jobs called that invention “as big a deal as the PC.”  Venture capitalist John Doerractually suggested it could be“bigger than the Internet.” The Segway is truly a technological marvel. The Segway was going to revolutionize intercity travel. Taxis, buses, bikes, and parking lots would all be gone.  Subway rails would be paved and turned into Segway paths and the trains sent to the junk yard.  Segway plug-in stations would crop up all around the city. Obviously, none of this happened; these days you can buy 100 Segways for the cost of one Tesla Model 3.  Maybe eventually we will see the long arm of the market and lifestyle bring the Segway into mainstream use to reduce pollution in our cities. But meanwhile…..

CTOs, scientists, and executives are always looking for the newest innovations. Entrepreneurs, corporate executives, and marketing management are always looking to gain a competitive advantage through the use of advanced technology. And me—I believe there is no such thing as disruptive technology.  Advanced technologies are not original; they have been built on the backs of millions of scientists, engineers, and innovators for thousands of years.  What we are seeing is clever people using advanced technology to build a business by gaining a competitive advantage that results in substantial market disturbance.

By the way, the core technology in Bitcoin is the “Byzantine General's Algorithm”

On this day we celebrate our presidents. Today, you should ask yourself “Would you make a good president? As a project or product manager what skills would bring to oval office that would be helpful? Would Scrum Master skills be helpdul. If you are a project sponsor would your skills be helpful?  These are the questions and answers I set out to find when researching my book, The Dead Presidents' Guide to Project Management.  More importantly what are the lessons that these 40 men can give us to be better project managers and sponsors.  In looking at the lives of these men we can find solutions to our own situations and issues. 

The President of the United States is a good project manager.  Like a project manager, the president must use his or her domain knowledge, skills, tools and techniques to manage and create activities in order to meet or exceed the citizens of the United States’ expectations. The president of United States is servant-leader. Servant leadership is defined as the skill to influence people to work enthusiastically toward goals identified as being for the common good.  The president of United States must have good connections to be an effective leader.  The president of United States must be a good negotiator. The president of the United States must be able to deliver bad news early and bravely with solutions. 

The President of the United States is also a good executive sponsor.  Like a good executive sponsor, the President of the United States must inspire people.The president’s inspiration is infectious, and showing enthusiasm has inspired the country to do great things. The President of the United States must have a succinct vision with clarity of purpose. A succinct vision is concise and to the point. Clarity of purpose begins with a common understanding of the action needed to accomplish the vision. The President of the United States must be able to effectively distribute decision power. The President of the United States must understand the process of government to get anything done.

The Dead Presidents’ Guide to Project Management considers lessons learned that these great men have bestowed upon us. The job of president of the United States requires many of the same leadership skills, knowledge, and characteristics you need to be a good executive sponsor, project manager, teammate, collaborator, and person. This guide provides you with a deeper understanding on how these leaders used many of these skills to improve the United States of America. This deeper understanding will allow you to relate adroitly and effectively to your own situation and environment. This guide will also help you to become a more interesting person.

Get your own by going to LuLu.

“Jim and Evan have provided a valuable set of insights and tools for you to learn about teams and how to become a team member—a “teammate,” in their terminology. Jim has experienced the surge in success, value, and productivity resulting from team-based development. For years, his “CHAOS Report” has statistically chronicled those improvements. For his part, Evan has seen the devastation that role-based reward systems wreak on marriages, families, and communities. He brings to the table the experiences, techniques, and ideas that result in successful team-based thinking.”

~Ken Schwaber, Agile Manifesto signatory, Scrum creator and evangelist

“The Good Mate is our attempt to provide you with some basic guidance about how to behave and interact with your other teammates as an individual in a self- directed team. The Good Mate provides 50 basic skills you can use to improve as a teammate to make your self-directed team a success.”

~Professor Jim Johnson

“Our goal is to help you learn the skills and tools that we know work in successful relationships.”

~Professor Evan Sorensen

“In their work, Jim Johnson and Evan Sorensen have created a hands-on approach from the perspective of the individual team player and how they can contribute in building successful and self-directed teams.”

~Prof. dr. Steven De Haes, Antwerp Management School – University of Antwerp

How understanding team relationships can make you happier and more

To get the workbook come to our workshop: sign-up in the store

A good example of the application of micro-learning can be found at the Dutch Police Academy. Within the academy’s Future-Oriented Development course, new strategies for the police are tested through micro-experiments. Students are able to mount experiments and to see how those experiments fit into the larger context of police strategy, as well as ensuring that their contribution reinforces that strategy. This bottom-up connection with the large top-down strategy through small strategic initiatives on the shop floor is not new; in fact, it dates back to the 1980s, when the management and strategy scientist Henry Mintzberg distinguished larger, top-down “planned” strategies from small, innovative “emergent” strategies.

Within the Police Academy, micro-learning is used to reinforce what is already in place for strategy, as a blueprint andas a dot on the horizon. Through doing small experiments, the students at the Police Academy develop strategic initiatives from continuouspractice. This helps everyone to realize that what we do in daily practice is influenced by strategy. Mintzberg says that we need to see the operational process as a strategic theme. In the police organization that is very important, because the operations of police work is subject to disruptive change, such as cybercrime. Combining thinking and doing actually improves adaptive ability for both employees and units, thereby reducing decision times. Value and commitment are both created and accelerated with the adoption of a new method or technology from micro-learning experiments. In effect, through watching and listening when they do not know the outcome in advance, participants are allowed to truly look and learn. The goal is for participants to learn to create a design for a sustainable experiment—and then implement that experiment, followed by open and collegial discussion of its effects. 

The above is an excerpt from an article written by Hans Mulder, with the support of Roel Verhaert of the City of Antwerp and Benito Shukrula of the Police Academy of The Netherlands, titled ”ICT Innovates the Organization by Micro-experiments and Micro-learnings” and published in AGConnecton (Date). Go to (link)

Hancock went on to say that it is the responsibility of the executives to ask the right questions. As an executive, you cannot say “I didn’t know” when something goes wrong. The comeback is, why didn’t you know? You are the CEO. That means you have the responsibility to ask the right questions. You’re expected to understand and monitor the ethos of your organization. It’s a culture issue, not a management issue and, as has been said, a fish rots from the head down. Wex International’s George Hogan suggests, in another pm2go blog, that executives are responsible for creating and maintaining a culture of trust, honor, and ethics. This creates user trust. 

The right question for me is “Do I have confidence that Zuckerberg and Sandberg will do the right thing to protect their users and their data?”  To be more specific, does Facebook, the organization, have the will to make changes that protect the data of their users?  The answer is—I’m not confident that they do.  The United States government, on the other hand, does have the ability to protect users from this type of abuse.  Europe, with the GDPR, is leading the way, and I call on US government leaders to do the same. 

The Standish Group is, of course, not concerned about loss or leakage of the information we provide, since most of our public posts are duplicated on Tweeter and Linkedin.  However, Facebook is capable of reaching beyond our information into the information and data of our contacts. Therefore, just being on Facebook exposes our customers, friends, family and general contacts to the company’s bad behavior. It would be irresponsible for us to continue using Facebook. To Facebook we say goodbye. And to you, we say—don’t find us on Facebook. 

By Jim Johnson

Feedback from some of the members suggested they rarely, if ever, have the opportunity to select their own project team. Another member stated, if we only had the luxury of choosing our own team.  They went on to say that team members work on multiple projects at one time and also support production applications. A member stated while he could see the advantage of being able to select a team to help ensure team members are actively engaged, he was not sure how he could do that in his organization. Also, there are conflicting priorities on multiple projects and competing executive sponsors that can prevent selecting and assigning your own optimum team.

They ask for suggestions how to get a team of their own, so here is what we have come up with as an idea. Start with an experiment and call it an experiment. First, select a skilled project sponsor and assign him/her to a small project or application.  If you do not have a skilled project sponsor, but have a person with a small project, have that person take our good sponsor class. Second, work with the sponsor to select a small team of 3 to 6 members of fairly good talent, but not too good. In your environment the best people seemed to be pulled off for other projects or production issues. So, for your sanity sake keep away from them. Set aside a special room or place for them to collaborate and work.  If possible have them try Scrum.  Then third execute the project without interruption. If it works out well, try to keep them together, build another small product, and simultaneously build another team for another small project. This creates multiple ‘project squads’ to be available going forward. However, do not be impatient and get carried away. You need to build your capability slowly. 

By Gene Kim, Kevin Behr, and George Spafford

(Portland, OR: IT Revolution Press, 2016)

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

By Gene Kim, Jez Humble, Patrick Debois, and John Willis

(Portland, OR: IT Revolution Press, 2016)

By Jim Johnson

It’s always nice to see another book out by an author you enjoyed. I had reviewed The Phoenix Projecton the May 10, 2016, CHAOS Tuesday radio program—I gave it 5 out of 5 butterflies and my recommendation. In fact, I approved the book for use in my latest master’s class at the Antwerp Management School, and three of my students reviewed it for submission to PM2GO (you can see their comments below).

Like The Phoenix Project, The DevOps Handbookis focused on educating, explaining, and pitching DevOps. However, the Handbook has a laser focus on the features, functions, and skills needed to implement and maintain a DevOps environment. The Phoenix Project (much like my book The Public Execution of Miss Scarlet) is a fictional tale of a project in trouble—and its rescue through DevOps.

The Phoenix Project received high marks from my colleague Bob Kelley,who found it “an enjoyable read.” Bob is an experienced CIO and a frequent contributor to both CHAOS Tuesday and PM2GO. (He admitted that he identified with Bill Palmer, the hero of the story.) My student Joseph Puthenpurackalagreed: “This book is highly recommended for anyone starting on a DevOps journey within their teams.” Another student, Frederic Crabbe,commented, “The underlying idea is to take the lean methodologies from manufacturing, and bring them to IT,” and a third, Han Dijckmans,noted that “organizational anti-patterns that commonly impede business and IT cooperation are nicely described.” (You can read their full reviews by clicking on their names.)  

As I explained above, The DevOps Handbookis an instruction manual and a roadmap for implementing and maintaining a DevOps environment.  It offers some insight into the practical ways that organizations can and have implemented DevOps.  It also provides concrete examples of organizations that have successfully implemented DevOps.  In addition, the authors recommend several tools that will help in the implementation.

I recommend both books, though I’m not sure in what order you should read them. Here’s what I think: If you are primarily a technical person, then you should read The DevOpsHandbookfirst and then use the insights you’ve gained there to understand how Bill Palmer became the hero of The Phoenix Project.  Basically, you can use the handbook as a reference.  If, however, your role is primarily in management, consider reading The Phoenix Projectfirst, and then move to the handbook. 

For 25 years, The Standish Group has been campaigning for the benefits of “small batches” (microprojects), the iterative process, continuous delivery, and fast feedback.   We have also crusaded in favor of “fast failure” and failure tolerance rather than “blaming and shaming.” Since both these books preach the same concepts, they provide a verification of our quarter century of project research.