Keys To Successful Postmortems - Part I: Setting Up the Meeting By Mark Calabrese Part of closing out any project, outage, service restoration team effort or any initiative whether successful or otherwise (and it’s even more critical on the “or otherwise”) is the postmortem. Too often, this milestone in the ‘Closing’ phase of a project is either [...]

What IT Managers Can Learn From the Failure of a British IT Project By Jim Anderson Note: This article also applies to IT Project Managers, that’s why PM Hut elected to publish it. The one thing that everyone in IT has learned is to stay away from projects that we just know are going to fail, right? It [...]

Fascinating presentation last night at the local PMI chapter by Dr. Tom Facklam on rescuing a project at a biotech firm. The company ran into serious problems during Phase III clinical trials of a breast cancer vaccine. This was a real life-or-death situation for the patients, and it also threatened the financial viability of the company.

The key success factors for surviving and resolving this project crisis apply to major problems on other projects:

Create a sense of urgency. Make sure everyone understands that you don’t have time to do things “properly”. Break down standard ways of working and ways of thinking. Fix first, document later.

Reassure the sponsors, customers and other stakeholders that your team can take care of the problem – even if you don’t know what the problem is yet, and if you don’t know how to fix it yet. Keep people (especially executives) from panicking, and secure a mandate to act.

Insist on an open, blameless environment. No witch hunts now or later. Prove to everyone that they can bring up information without repercussions. All that matters is fixing the problem.

Put the customer first. Don't put the customer at risk, don’t hide things from them, don’t try to “protect” them.

Communicate constantly. Be transparent. No spin. Stick to the facts – what you know, what you don’t know, what you are doing about it.

Brainstorm. Encourage people to try things even if it doesn’t make sense. Run multiple concurrent experiments until the data starts to converge on the problems and on solutions.

As many of you know, I have expressed considerable skepticism about whether performance evaluations are even worth using, if they do more good than harm.  And Sam Culbert has gone the next step with his book, Get Rid of the Performance Evaluation. 

Even though this debate will continue to go on, the fact is that lawyers, HR executives, and the force of tradition -- and some rational reasons as well -- mean that most organizations aren't going to be getting rid of these things anytime soon. As such, I was talking with a senior HR executive and she asked me if I knew of any examples of good and simple performance evaluation forms -- the one her firm uses is way too complicated and she is looking for ideas about how to simplify it. 

I thought that was a great question. If we must use these things, they might as well be as short and effective as possible, despite their limits.  Can anyone help?  Has anyone ever used one or used one now? 

Please describe it in as much detail as you can and you get bonus points for sending a picture or pdf or something like that of the form.

  Thanks!

P.S. I just did a Google search for "Performance Evaluation Forms" and there are a lot of images of them... but it is tough to tell which are good or bad from looking at them -- I bet the form itself is a lot less important than the quality of conversation that happens before, during, and after people get the feedback.

[head] Building Blocks of Project Work Planning  [posted by] Marian Haus,... Marian Haus, PMP

Power to the Edge: Command and Control in the Information Age, speaks to the integration of traditional management with complex systems in the presence of agility, emergence, and variability of the real world.

This is a book about managing in the defense systems domain and the technology advances that push the decision making processes to the edge of system.

This is about architecture of the system. The human system, the techncial system, the operational system, and the governance system, and the environment in which these systems are embedded.

While the book is focused on military systems, it is applicable to other complex systems. Military systems have many if not most of the attributes of business systems.

They have strategy, emerging requirements, adversaries who want to put you at a disadvantage, limited budgets, limited time to deploy the solution, conflicts internally and externally that conspire to have your efforts fail.

The notion of centralized planning and decentralized execution has merit in modern software development processes and the business they support. Planning is NOT used in the way agile software developers use the word Planning - wrongly BTW. Planning in the defense domain, for defense processes, and the programs that deliver the systems used in those processes means Strategy Making.

All Planning is Strategy Making. So when you here an agilest say Responding the Change Over Following The Plan, they should really be saying following the schedule. The irony of course is even the formal DoD Earned Value Management world, there is a nice little form titled BCR (Budget Change Request) and its used all the time to make changes to the cost and scehdule baseline. Whym beacuse things change. But if we're changing our Strategy all the time, then there's a much bigger problem to solve.

Calculating Outcomes

To follow on a recent theme of what's wrong with populist book? is shown in this example. Integrating Air, Land, and Sea Operations, which speaks to integration of complex systems into a System of Systems that behaves in ways not definable in the beginning. This is done through intelligent agents at the nodes of the network. This is called network centric warfare.

The Integrated Master Plan (IMP) is a Strategy for the successful completion of the Program. Like all strategies, a set of hypothesis are needed to test the strategy. With these hypothesis testing processes, there is no way to known if the strategy - the Plan - will work.

This is a sample of a book where popular ideas are presented and at the same time actionable outcomes are provided.

We all know the saying Time flies when you’re having fun.  Are you helping your team’s time fly?  No matter how serious your project may be, it is still necessary to bring some levity to the situation.  Allowing the team to take a ‘life or death’ view of the project can be detrimental to the well-being of the team, and ultimately the project.  As the leader of the project team, it is your responsibility to make sure that your team can have a little bit of fun while they spend the majority of their time working with you.  As the Project Manager, it is sometimes necessary to put on your Jester Hat, while still maintaining the level of professionalism that is required.

via Flickr by E. E. Piphanies

Positive Word Choices: One of the best ways I’ve learned to help my team maintain a positive outlook is to constantly use positive words, regardless of the situation.  During one of my projects, the company was in bankruptcy, and many people were leaving the company.  This made it extremely difficult to work on the project, because we’d lose Subject Matter Experts, Testers, and Technicians so often, it sometimes felt like it happened every day.  Whenever I would get news that someone else had left, I’d respond with a single word – Fabulous. My tone of voice was not a happy or excited one, but I chose to use a positive word in the face of a negative situation.  At first, my team had a hard time understanding what I was doing, but took it as one of my (many) quirks.

Over the months of the project, the word “Fabulous” became the team’s motto.  People would count how many times the word ‘fabulous’ was spoken during Status Meetings, and people started to respond to negative situations with the word Fabulous almost instinctively.  Did it look like we weren’t going to finish the requirements on time?  Fabulous.  What do we need to do to make it happen?  Do we need to schedule another all-day workshop in a location that is only convenient for half of the team?  Fabulous.  Let’s pick a day that we think will have less traffic.  Did we just encounter some necessary scope creep?  Fabulous.  Let’s figure out how to work it in.

The word itself has very little to do with anything, but having a ‘fun word’ to use during a not-so-fun situation helped the team to rally around and tackle each situation as it came up.  Sometimes, when tensions were high, someone would simply shout the word “FABULOUS” and get a calming giggle from the rest of the team.  I was told later that I was heartily mocked for my pervasive use of the word, but that it really did help the team.  While others may have been insulted at being the target of such mockery, I was happy to put on my Jester Hat and allow the team to have a little fun.  I think it’s fabulous.

 

Bringing Fun into Meetings:  I have found very few people who enjoy meetings.  In fact, I found a quote by Thomas Sowell that demonstrates the general view of meetings quite perfectly:  People who enjoy meetings should not be in charge of anything.  However, I think that meetings haven’ t been given a chance to prove what they can be.  The problem is not with meetings themselves, but with the people that attend them.  If someone decides that they hate meetings, every meeting that they attend will be an arduous process that almost never ends well.  If that person is conducting the meeting, then it is almost guaranteed that none of the attendees are going to enjoy the process.  These are meetings that rarely accomplish anything, because many of the required attendees don’t go to the meeting.

via Flickr by MNicoleM

So how can you turn that around and run meetings that people want to attend?  Simple – make it fun!  Bring a sense of humor and levity to the meeting.  When people call in, greet them with a cheer!  Start every Status Meeting by acknowledging accomplishments from the week before.  Recognition of a job well done is great for morale, and puts a positive spin on the rest of your meeting.  Also, maintaining order in meetings and not allowing side-conversations to take up too much time is an important part of keeping your meeting attendees engaged in the meeting.  I’ve heard a number of codewords that are used by project teams to point out that the conversation has gotten off track, but I’ve got two favorites that are very funny while still getting to the point:

1. E.L.M.O – (Enough, Let’s Move On)
2. Shiny ball (I think we all know how easy it is to get distracted by shiny things rolling around)

When you ensure that your meetings stay on track, you are showing the attendees that you respect everyone’s time by not allowing the meeting to go long regarding subjects that don’t necessarily affect everyone in the meeting.  When you do so with a sense of humor and levity, you are not overpowering the people who got sidetracked – simply guiding them back to the predetermined path, otherwise known as the meeting agenda.

 

Generally, projects have a reputation of being overly stressful and almost always ending in a ‘Death March’.  Don’t allow your team to fall into that trap.  Put on your Jester Hat and do everything you can to keep the project team amused with what they are doing.  By helping your team maintain a reasonable balance between amusement and stress, you can improve morale and productivity at the very least.  You may even keep some stress-related health issues away from your valued team-members by allowing them to laugh every once in a while.  Remember, a happy project team is a Fabulous project team!

Agile Project Charter By Terry Bunio With the current project I am working on we discussed how we can make the Project Charter or Project Kick-off activities much more Agile. We are proposing to use new Agile methods and want to enhance our communication and allow team members to easily understand what they would be doing on [...]

 

In my recent post Charting a Course for Corporate Success, I outlined three, broad categories of innovation:

• Disruptive, Breakthrough Innovations.
• Sustaining, High-Value Change.
• Everyday Creativity and Emergent Innovation.

When it comes to leading businesses, it is important that we don’t just come up with new things; we need to innovate in ways that create value for our customers. As research by Robert Wolcott and Mohanbir Sawhney demonstrates, there are many different ways that business can innovate to achieve this outcome. They came up with twelve dimensions of innovation that we can consider:

Offerings: These are new products and services that are valued by the customer, like the iPhone.

Platform: A platform is a set of common components, assembly methods, or technologies that are building blocks that can be leveraged with a portfolio of products or services, allowing you to create a set of derivative offerings faster and easier than building them all from scratch.

Solutions: This involves creating a customized, integrated combination of products, services, and information to solve a customer’s problem. This can be an end-to-end solution that simplifies and reduces the logistics of something like procurement and delivery, for example.

Customers: The identification of new customer segments or unmet needs.

Customer Experience: This involves any and all things that a customer feels, hears, sees, and experiences in dealing with your company.

Value Capture: Innovation that discovers untapped revenue streams or expands the ability to capture value from interactions with customers.

Process: This type of innovation concentrates on the internal business activities and improving the efficiency of those processes.

Organization: This is a redesign of organizational structure and a company’s activities, possibly redesigning roles, responsibilities, and incentives of different business units and individuals.

Supply Chain: This involves re-sequencing activities and agents in the sourcing and delivery of goods and services.

Presence: This type of innovation focuses on the creation of new distribution channels or new ways of leveraging existing channels.

Networking: Innovation that concentrates on how products and services are connected to customers and how to improve and use those connections to create competitive advantage.

Brand: Brands communicates a promise to customers, and innovation in this realm involves extending the brand in some way.

Welcome to the January/February 2012 edition of the Carnival of Project Management. The Carnival is a round up of the best project management articles (according to me) over the last two months.

Brad Egeland presents Watch Out for Warning Signs posted at Project Management Tips, saying, “Four warning signs that things may not be going well with your project and how to tackle them.”

Bruce McGraw presents Cognitive Science Insights into Decision Making posted at Fear No Project Blog, saying, “how you make your decisions? Are you watching for other cognitive clues from staff and stakeholders?”

Luis Seabra Coelho presents Using Mind Maps: how and what for. Luis blogs at ah-ha-moments.net. Mind maps can be a useful tool in project management.

Ty Kiisel presents Crude Confrontation Curtails Collaboration posted at Work Management Blog. “Effective communication is personal,” he says. “It doesn’t matter if it’s face to face, via email, or even in a blog — it’s one person interacting with another.”

Lindsay Scott presents Emphasize “Management” in PM posted at Michael Greer’s PM Resources blog, saying, “Put the emphasis on management back into project management.”

Soma Bhattacharya presents Who’s your boss?, which she’s written on her blog for newbie project managers, Stepping into Project Management. She has presented an interesting take on personality types – recognise anyone?

Finally, I’ve come across a new website called MBA Online which aims to educate people on a number of topics including company culture, productivity and leadership. You can choose your own course and then follow a thread through to learn about the basics and new advances in the subject.

That concludes this edition. Submit your blog article to the next edition of Carnival of Project Management using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.

Related posts:

1. Carnival of project management #1 Welcome to the August 14, 2006 edition of carnival of project management, a round-up of PM articles on other blogs. Pawel Brodzinski presents When Everything...
2. Carnival of project management #3 How is it possible to ladder a pair of fishnet tights? They already have holes in. Fishnets are, for the second autumn in a row,...
3. Carnival of Project Management #23 Welcome to the October/November, 2008 edition of the Carnival of Project Management.  Over 90 entries, most of which were dross, so I have sorted out...

You've heard the phrase "All models are wrong: Some are useful," by George Box, a chemist who taught himself to be a statistician.  My takeaway from this is that all models - and that is everything written down in all management texts and training manuals everywhere - is that the model is a lens to look at a problem through.

When I was an undergraduate at university studying marketing we were discussing the Marketing Mix.  "When launching or developing a product..." the lecturer said, "pay attention to Price, Promotion, Product and Place..."

I sat there thinking.  I didn't have corporate experience and this didn't make sense.  It just seemed to simple and to pat. (Four Ps!)  I was trying to learn this stuff by applying it to the bar and restaurant jobs I had.

How can I apply the four Ps to the restaurant?  We can't move it, especially me as a waiter, so the distribution aspect is a moot point.  Maybe we can change the prices and the menu (product) and sure we could do something to raise the bar when it came to promotion.  But what about the other aspects - the relationships the staff had with each other, the way we interacted with the customers, the suppliers (especially the alcohol sales reps!)

So I said as much to my lecturer; "This doesn't seem to be enough.  Surely you need to think through more than this to launch and manage products."

It was then I got one of the best nuggets of information from that degree.

"It's just a checklist to help you along.  It doesn't give you all the answers.  You have to use your brain to solve complex problems."

I wonder how he remembers the conversation, if at all.

The current version of The New Yorker has a wonderful article by Jonah Lehrer called "Groupthink" (you can see the abstract here).  It does a great job of showing how creativity is a social process, cites wonderful research by Brian Uzzi showing that when people have experience working together in the past they produce more successful Broadway musicals (up to a point, too many old friends is as bad as too few), and offers research showing that groups where members engage in constructive conflict are more creative -- all themes I have talked about at various times on this blog. 

I do however have a major quibble.  At one point, Lehrer states flatly that brainstorming doesn't work.  He later quotes creativity researcher Keith Sawyer as saying that people are more efficient at generating ideas when they work alone than in groups, something that is well-established.  But that is not the same as saying there is conclusive evidence they don't work.

I once devoted way too much time to the question of whether this research shows that brainstorming is useless. In the name of full-disclosure, please note I am a Fellow at IDEO and also a co-founder of the Stanford d.school, which both use brainstorming a lot. But I am not at all a religious zealot about the method. I see it as just one sometimes useful method, and I have often said that the d.school in particular should spend less time teaching brainstorming and more time teaching people how to fight. (And if you want evidence that the d.school believes in more than just brainstorming, look at their Bootleg.)

But please consider several facts about the brainstorming literature, at least as it stood about 7 or 8 years ago when I last reviewed it carefully and which is consistent with a more recent paper from The Academy of Management Review (Here is the abstract, which is quite short):

1. Nearly all brainstorming research is done with people who have no training or experience in doing or leading brainstorming. In fact, there is at least one study showing that, when facilitated well, the so called productivity loss disappears. 

2. As Keith Sawyer's comment implies, nearly all this research looks at only one measure of effectiveness, how quickly people can produce ideas.  Because people in groups have to take time to listen to each other, it slows the idea generation process. Most brainstorming studies compare the speed at which people generate ideas such as "what can you do with a brick" when sitting alone and talking into microphone versus doing so in face-to-face groups. In fact, if creativity is about both talking and listening, if you look at the data from these same studies, I once figured out that people are exposed to substantially more ideas per unit of time when you compare group to solo brainstorming -- and I would argue that talking and listening are both key elements of the social process underlying creativity.

3.A key part of face-to-face brainstorming is building on and combining the ideas of others.  This comparison is impossible in most brainstorming studies because an individual working alone is not exposed to the ideas of others.

Indeed, one of the very first posts I did on this blog in 2006  dug on this issue.  As I wrote then, "To put it another way, if these were studies of sexual performance, it would be like drawing inferences about what happens with experienced couples on the basis of research done only with virgins during the first time they had sex." I also wrote about brainstorming here in BusinessWeek and they started with this setup.

The upshot of my research and my reading of brainstorming experiments is that, if you are just looking at the speed at which an individual can spew out ideas, individual brainstorming is likely superior. But if you look at the range of positive effects has at a place like IDEO -- spreading ideas around the company, teaching newcomers and reminding veterans of solutions and technologies and who knows what,  providing variety and intrinsically satisfying breaks for designers working on other projects, creating what I called a functional status contests where designers compete politely to show off their creativity (a key job skill), and impressing clients, brainstorming may have numerous other positive benefits in real organizations where creative work is done -- none of which have not been examined in those simple experiments.  If so, those findings about pure efficiency may well be beside the point when it comes to evaluating brainstorming in organizations that use it routinely.

In short, I believe that Lehrer's statement that brainstorming "doesn't work" is too sweeping because it has not been studied adequately in real organizations or with people who have real brainstorming skills. Again, I would describe this as a quibble; the article in The New Yorker is otherwise excellent.

P.S. for the true nerds, here is the 1996 academic article on brainstorming that Andy Hargadon and I wrote:

Download ASQ Storming

I get a lot of questions about how to use LiquidPlanner for (or in addition to) bug tracking software.  We have LiquidPlanner customers doing both, depending on the nature of their team, the systems that are already in place, etc. Several customers are using our API to integrate with GitHub, Jira, and Bugzilla. Internally, we use LiquidPlanner and only LiquidPlanner for filing, tracking, collaborating on, and verifying bugs & incidents.

Why? At the end of the day, we want to track bugs along with the rest of our work—in our schedule. Bugs need to be assigned, estimated, and prioritized alongside our project work, based on their severity and impact. We fix bugs (new and existing) in every release of LiquidPlanner, and since LiquidPlanner is the one system we all look at every day, it doesn’t make sense for us to track them in a separate system.

But how, you might ask, does it actually work? Here are the gory details.

First, we have a single place to collect new bugs.  They all get sent to a Package called “UNTRIAGED,” which is the central holding place for new bugs, feature requests, ideas, and tasks until we can process them (Figure 1).  This Package has a relatively high priority position in the "Projects" page of LiquidPlanner, just under our urgent work and active sprint releases.

For us, bugs come to our attention in a variety of ways. They might be reported by a customer via email, found during the testing process or through our normal use of the tool, or sent to us as a system alert.

To get these items into LiquidPlanner, most of us use email integration. This “UNTRIAGED” Package has its own email address, which we’ve all added to our address books. When we mail an issue into LiquidPlanner, we automatically create a new “task” for tracking.

Using the subject line of the email, we can:

• Name the bug (usually it starts with “Bug: XXXXX”)
• Assign the bug to any member of our workspace
• Estimate it in any unit we want (2-4h, .5-1d)

The attached documents and body of the email (including screenshots, repro steps, or error messaging) get saved to the Details page of LiquidPlanner, ensuring that all relevant information stays with the item as it goes through our workflow.

Next, we have twice-weekly meetings to process our “UNTRIAGED” bugs. During those meetings, we review every new item, and assign, estimate, and prioritize it. Some bugs get moved into the current sprint, others get pushed into the staging sprint or out to the backlog. If a new bug is assigned to a developer, they get notified via email and it shows up on their personal tasklist.

We typically structure the work in each release into several major categories, one of which is “Bugs.” This allows us to view, analyze, and report on them as a group, separate from other tasks like new features or tech debt. However, as you can see in Figure 2, the amount of work associated with bugs is non-trivial – hence our interest in tracking them in conjunction with our other project work!

All comments, collaboration, updates, and files associated with the bugs are stored on the Details Page. This includes references to specific customers who may have been affected.  Sometimes this information can pile up, but since the most recent comments, documents, and links are added to the top of the list, it’s pretty easy to stay on top of the latest happenings for each item. We also have LiquidPlanner integrated with our source control system, so that applicable references/commit notifications are automatically added as comments to the bug.

Finally, once the bug has been fixed, we assign it back to the creator (or a tester) for verification. By simply switching ownership of the task, we can move it through an informal workflow that doesn’t bog us down in process. (The person who created the item is also notified by email that they have a new assignment.) Once the fix has been verified, the item is marked done and becomes part of our (fully searchable) archive for later reference.  Voilà!

We recently added new custom fields that allow us to track our bugs even more effectively. We've created a custom field for "bugs", "feature requests", etc. And, when a new issue comes up, we simply assign the appropriate custom field. This is great for filtering in the plan and for reporting purposes!

Naturally, you can argue that LiquidPlanner lacks some of the features of a dedicated bug management system. I’ll give you that. But what it lacks in dedicated features it makes up for in ease of use, simplicity, and integration into our other processes.

Did you ever experience the phenomenon were the project status is red but getting greener and greener when climbing to the to top of the management ladder? This is named “Watermelon reporting”. This video explains the main reasons for this behavior and gives the right tools to fight messy reporting processes. You will learn practical tools and ideas that can be used to get rid of or at least minimize dysfunctional reporting behavior in your own teams and company. Video Producer: Agile Central Europe Conference

Decisions that directly affect Information Technology (IT) projects or IT services within an organization are not always made in the IT (or Engineering) department. That is not bad thing; it is just the way things are and how business runs. Like what? Management decides it is in the company’s strategic interest to form a partnership [...]

This video describe reasons for working remotely as a programmer. It presents a couple of useful habits of the remote worker and then focus on working effectively in a distributed team. There is a huge difference between just being a remote worker and being a member of a distributed team. The presentation discusses agile teams working on a distributed basis and presents some helpful software tools. Video Producer: http://agilece.com/

Lead, Follow, Or Leave By Simon Jackson It was Thomas Paine who said we should lead, follow, or get out of the way. Following is rarely considered a leadership skill but I think is one of the most important. Leadership is not the same thing as management, direction, or control. Leadership is a state of mind, not [...]

When there are statements like this, in the absence of a domain and a context of a domain, it just reinforces why I don't recommend you read any populist books on a topic if you have any skills at all of getting to the first level of actual technical context for that topic.

Taken from a recent blog post on "complexity thinking" with 4 populist management book references

 

So let's start here with a survey of the topic from the non-populist point of view - that is actionable. That is from the point of view of people who want to calculate something, make a decision on the outcomes from that analysis.

 

Nothing wrong what so ever with those populist approaches. But one test that has served me well over the decades is can I calculate something with this person's product (book, paper, or article)?

No? Then I may not be able to calculate something directly from the author's work, but I'd better be able to find out how to do it in an appendix or a reference.

Still a No? Then is there something there that will lead me to the next level of understanding where I can start to see how I can calculate something. Here's the recent example about Moving Beyond Populist Books.

What's this means is that while the populist books may be informative to many - and we need a lot more informed people than we have now - these populist books and materials quickly run out of steam when we want to actually make a decision that involves money, time, resources, risk, commitment of someone else's stuff. In other words we need to know quantitatively and analytically what the probability of success will be if we follow that authors advise.These populist books play a role of starting the conversation, but fail to complete the conversation - in many cases - with actionable outcomes. They point out the problem but not the actions need to create the solution. Knowing the problem is necessary but not sufficient.

I can hear the populist authors squawking now.

What! How dare you critize my popularizaiton of this critically important topic with your lame need to actually apply this idea in a quantifiable manner. 

But their role is to popularize a topic, not necessary do the calculations needed to solve problems with the popularization.

So if you look at the reading list of the paper above, you'll see books, papers, articles that DO provide actionable outcomes. Once you've digested the populist ideas, take a tour of those to see if there is anything there you can put to work on your own complexity management problem.

Don't get me wrong. Populist books are fine. But they are just that populist not the engineering books I need to work the problems in front of me.

For some more background on complex systems in the world I work see:

• NDIA Human Systems
• Verification and Validation in Complex Adaptive Systems
• Cybe Space: The Ultimate Adaptive System and the Operationalizing Agility 
• The Agility Advantage: A Survivall Guide for Complex Enterprises and Endeavors. This eBook will freak out the agilest who don't understand the notion of Command and Control is mission critical paradigms, where agility must operate in the presence of 100% Mission Success.

Project Management: Fix the “Fail to Plan” Syndrome By Carol Dekkers You’ve probably heard the popular saying: No one plans to fail, but often we fail to plan! Did you know that the most common method of software development today (according to author Steve McConnell) is “Code & Fix”? Code and Fix is the method whereby requirements are [...]