This is a parking lot for other ideas that may get a home in some of the lower-level sections, or elsewhere in this collaborative book. The current parking lot of ideas includes:

1. Plan and work concurrently, and tune plans based upon how well they are working
2. Create, deploy, and evolve architectures which provide for flexibility, exploration, autonomy, and scalability; exploit experienced architects to do that work
3. Collect and validate business information at it's source, and roll that information up into periodic business reviews where decisions are made in a structured fashion against a set of documented criteria
4. Establish a centralized sources of up-to-date project status information
5. Develop, evaluate, and improve capabilities in small increments, with active customer involvement
6. Focus attention on value streams (threads of overall activity which provide high value, or are felt to require the highest attention)
7. Establish and utilize tight feedback loops to facilitate mid-course corrections towards goals
8. Invest in infrastructure to interconnect, leverage, and tailor existing capabilities
9. Collect, aggregate, and integrate assets into an accessible repository that people depend upon to do their work, and that provides an ability to rapidly evolve to meet the needs of those people.
10. Leverage modeling to improve understanding of trends and alternatives
11. the customer's operational perspective must drive decisionmaking, even though they may not have one yet
12. Have a lifecycle orientation. Delivering object code, rather than source code, in software reuse didn't create an explosion in reuse. - If problems were discovered with reusable parts, someone had to be available to maintain the code, and no one could figure out a 'sustainable' business model that would work to fund just the 'fixes', rather than drawing from a stream of new functionality (a key part of most product business cases). What worked, instead, was to create an environment that made it possible to fix it yourself, and provide access to other users and things they might have fixed as well, rather than depending upon a support contract to bail you out. It turned out that this became a very scalable model.

The remainder of this article is an early sketch of content to be included in the book Transforming knowledge and vision into action

Successful organizations in this environment typically achieve their success because they have established a foundation of envisioning, entrepreneurship, incentives, accountability, decision-making, mentorship,and change management. This foundation is used to motivate teams to make the required changes, ensure that new ways of doing work are the easiest options for the teams to take, and lighten the burden of making the transition to the new ways of doing business (rather than introducing additional obligations or distractions on top of what they already have on their plate). (Need to capture some words around using ideas from agile software movement, specially Scrum, for short cycles, tight user involvement, etc. Direction benefits predictibility, which may work well for internal projects, but not necessarily external markets).

Also good to emphasize power of communications (see Xerox paper) and how people are really spending their time (see Alistair Cockburn): Hypothesize and experiment! Prototype! Architect around the known and the unknown! Brainstorm useful protocols! Look for a foundation to build on. Progressively evolve the following material (likely drawn from other sources, though at present not attributed):

In project planning, the first level of precision is simply to say what general functionality comes out in each release, and what the release dependencies are. The second level adds interteam dependencies, naming the deliverables. The third level looks at each team's schedule, based on milestones with respect to reviews and delivering deliverables to other teams. The fourth is the total team project plan with task breakdown.

In requirements, the first level of precision is just the actor and the actor's goal with respect to the system, and the priority of delivering that goal. the second adds the successful scenario and primary failure conditions, frequency, duration of use, cost of construction and external system interfaces. the third adds the rest of the functional and non-functional requirements around the goal.

In object-oriented design, the first level of precision is simply to name the object and its primary responsibility toward the functioning of the system. the second adds sub-responsibilities and collaborations the third adds public function signatures, static relationships and data members. I want to note here, for you object-oriented modelers, that when you start using OMT, you are already at the third level of precision. Odds are, you haven't dealt with the first two yet. That is rather like not knowing whether the bookshelf is going to be 4 or 6 feet long, but trying to decide whether the next decimal place will be point-2 or point-3.

I have seen magnificent business modeling sessions wasted because the modelers chased each item down to the third or fourth level of precision I have modeled an entire telephone customer service operation with non-object-oriented business experts in just a week and a half. They paid for the session handsomely within a few months, when they were able to describe their needs for brand new sorts of services in a clean, simple and implementable way. We did this by ensuring that our modeling never went beyond two places of precision, which mean that we could cover their entire operation in a much shorter period of time. the fourth and final level of precision for OO design is the code itself.

In general, I have found that precision, as well as the other parts of PARTS, applies to every deliverable on the project. Accuracy has to do with correctness. I borrow from Luke Hohmann, in his book, "Journey of a Software Engineer", the notion of burning pancakes. How edible do you want your pancakes? Sort-of round, but possibly burnt? My first pancakes are usually raw on the first side and burnt on the other side. So of course I make just one to start with. Do you need them just edible? or restaurant quality? Edibilty makes a good measure of accuracy on a software project. Accuracy feed right into iterative development. We ask for "a burnt pancake" when we mean we want to see movement on the issue, even if the outcome isn't going to be pretty. We ask for a burnt pancake on the first integration run, on the first project plan, on the first business model (at the first level of precision, of course). We want "just edible" on the first level of precision when we work through the second level of precision, and we need restaurant quality to ship.

Relevance is easy. When we talking about the domain model, we don't want to see the user interface classes, and vice versa. Tolerance has to do with adherence to standards. Do we have to indent blocks three spaces to be in conformance the coding standard, or can we indent just two, or a full tab stop? Do I have to use Microsoft Project, or can I use a spreadsheet? How may I bend the rules of the project and still be a good citizen? Finally, scale has to do with how much you cram into one piece of a picture.

Organizations which are successful in tackling unprecedented challenges tend to follow a set of problem-solving patterns. While others have explored this notion of effective problem solving patterns in some detail, several additional patterns have been identified which are consistent with all of the previous initiatives, but are not explicitly identified by those frameworks. These strategies form a synergistic collection; the parts interact and collectively yield improvements that are greater than the sum of their individual parts. The patterns are organized as broad themes, and consist of the following: