Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
In a conversation on Twitter with Sridhar, there was mention that product development software projects are different than internal IT projects. And that how they are run is much different as well. This may be the case. It's not been the case in my experience in Enterprise IT for those internal projects. My experience in product development (FileNet, Triconex, Kontron) and software intensive program delivery for government, defense, space, and energy clients is that projects are expected to show upÂ on or before the planned date,Â at or below the planned cost and with the agreed set of minimal capabilities to accomplish the business goals or fulfill the needed mission.
When internal IT projects lose their ability to show up on time, on budget, with the needed capabilities - all within the probabilistically defined bounds of those measures - then they lose their seat at the table. Internal IT becomes a cost. Sometimes aÂ sunk cost. An expense. A necessary expense, but an expense all the same. And when you're only an expense, those making decisions tend to treat you differently. You have no tangible way to show your worth. In business worth is defined by revenue or cost savings. In both cases worth is defined in units ofÂ money. When you have only cash outflow you're likely not to be in the conversation about how to run the business.
There are endless books, articles, and academic papers on the topic ofÂ getting a seat at the table. Successfully delivering internal IT in support of the business. Keeping your seat the table on that business requires very specific behaviours, starting with three simple questions:
But the bigger question - theÂ killer question is what are we building and why are we building it? Ignoring for the moment the problem of showing up late and over budget dilutes any value produced by the project, some times to ZERO, we must have a notion of whatÂ DONE looks like in units of measure meaningful to the decision makers. Those paying the bills for the project.
Below is a briefing of how to answer theseÂ governanceÂ questions aboutÂ whatÂ andÂ why. With that in hand theÂ how much, when, and working are straight forward.Â
Using balanced scorecard to build a project focused org2 from Glen Alleman Here are two books that have informed my journany on the path to providing value through the management of Enterprise IT projects.
There are many books on Balanced Scorecard. Some I find best are:
At The End of the Day
If you can't say, with some degree of confidence, how much you plan to spend, over what period of time, to deliver some tangible value to those paying for your work, you're not in the room when those paying for the work ae deciding what they want you to do. You're considered an expense - possibly a valuable expense.Â
Hey, it's HighScalability time:
Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...
The happiness of people doesnâ€™t necessarily lead to improvement of their work.
Systems thinking is a powerful concept that can generate significant for value for organizations by generating more options which Dan and Chip Heath indicate is a precursor to better decisions in their book Decisive. Given the power of the concept and the value it can deliver, one would expect the concept to be used more. The problem is that systems thinking is not always straightforward.Â The difficulties with using systems thinking fall in to three categories.
Organizational boundaries and their impact of the flow of both work and information have been a source of discussion and academic study for years.Â Boundaries are a key tool for defining teams and providing a send of belonging, however some boundaries not very porous. As noted in our articles on cognitive biases, groups tend to develop numerous psychological tools to identify and protect their members.Â Systems, in most cases, cut across those organizational boundaries. In order to effectively develop an understanding of a system and then to affect a change to that system, members of each organizational unit that touches the system need to be involved (involvement can range from simple awareness to active process changes). When changes are limited due to span of control or a failure to see the big picture, they can be focused on parts of a process that even if perfectly optimized will not translate to the delivery of increased business value.Â In a recent interview for SPaMcast, author Michael West provided examples of a large telecommunication company that implemented a drive to six sigma quality in its handsets only to find out that pursuing the goal made the handset too expensive to succeed in the market. In this case the silos between IT, manufacturing and marketing allowed a change initiative to succeed (sort of) while harming the overall organization.
The second category is complexity.Â Even simple systems are complex. Complexity can be caused by the breadth of a system. Â Â For example, consider the relatively simple product of a lawn service.Â How many processes and steps are required to attract and sign-up customers, then secure the equipment and employees to perform the job, schedule the service, actually deliver the service and then to collect payment. The simple system becomes more complex as we broaden the scope of our understanding.Â Add in the impact of a variable like weather or an employee calling in sick and things get interesting.Â Really complicated systems such as the manufacturing and sale of an automobile can be quite mind numbing in its complexity.Â The natural strategy when faced with this level of complexity is to focus on parts of the overall system. This can lead to optimizations that do not translate to the bottom line. A second natural strategy for dealing with complexity is to develop models. All models are abstractions, and while abstractions are needed, you need to strike a balance so that the ideas generated from studying the model or results of experiments or pilots run against the model are representative of results in the real world.Â For example, letâ€™s say you build a 1/8 scale replica of a server farm.Â The replica is a model that could be used to study how the servers would be placed or used to plan how they would be accessed for service. This would be a valid use of a model.Â But if the model was placed in the actual server room and the observation used to jump to the conclusion that since the model fit, the server farm would fit, a mistake could quite possibly be made. Because of the complexity, we tend to focus on a part of system or to make abstractions. However, both can make it hard to think about the big picture needed to apply systems thinking.Â
The final difficulty with the use of systems thinking is the pressure of the day-to-day.Â As I noted when I re-read The 7 Habits of Highly Effective People, the urgent and important issues of the day can easily overwhelm the important and but not urgent. The use of systems thinking and the systemic changes identified through the use of the tool will generally fall into the important but not urgent category.Â A person who is having a heart attack due to cholesterol clogged arteries needs to deal with urgency of the attack before identifying and addressing their diet and other root causes. Leveraging systems thinking as a tool to address large-scale systemic issues is not a magic wand, rather a concept that will require time and effort to use.Â If the organization is being overcome by day-to-day events, systems thinking will be difficult to use.Â One technique that I have seen to deal with this scenario is to create a cross-functional, highly focused (tiger team) with a specific time box to start the process. This will require removing the teamâ€™s day-to-day responsibilities until the team meets it’s goal. This is a very difficult tactic to use as the people you would want on the team are generally the best at their job. This can potentially have a negatively impact organizational performance for a short period of time. You must consider the ROI.
The use of systems thinking is not for the faint of heart.Â There are difficulties in applying the concept.Â Boundaries, complexity and day-to-day pressures are the most significant, however there are others such as ensuring the team has system thinking training. Systems thinking can deliver a broad overall perspective and great value, but as a leader you must balance the difficulties with the benefits.
A few years back I used Small Basic as an early introduction to programming for my 2 young children (at the time 9 and 5). Small Basicâ€™s library has a nice simple API for drawing shapes and moving a turtle around the screen which the kids loved. However I found the lack of function arguments and return values was quite limiting from a teaching perspective. After creating shapes we wanted to refactor the code so that the drawing procedures could be parameterized, which can only be achieved with global state. Not wanting to get my kids in to bad habits early we swiftly moved on to F#.
Coincidentally Small Basicâ€™s library is a .Net assembly that can be easily consumed from C#, F# and VB.Net, which Iâ€™ve used once while introducing C# programming to adult beginners.
Inspired by Small Basicâ€™s simplicity, Iâ€™ve also built an open source library along similar lines called SmallSharp which Iâ€™ve used on occasion to introduce programming in F#. I feel the ability to start drawing shapes on the screen with just a few commands gives a real sense of excitement and achievement. The Processing language is another good option in this space. In contrast large frameworks like WinForms and WPF, although highly customizable, typically require a lot of work up front before you see any results.
In the previous three articles Iâ€™ve described steps to building a Small Basic compiler. First creating an abstract syntax tree (AST) with F# discriminated unions, then parsing with the FParsec parser combinator library and finally transforming to CIL with reflection emit.
The source code including the function procedure extension is available on BitBucket.
Extending the AST
First off the AST must be extended to support function declarations:
| Sub of identifier * string list | EndSub // Language extensions | Function of identifier * string list | EndFunction
Next a way is needed to call functions:
and invoke = | Method of string * string * expr list | PropertyGet of string * string | Call of string * expr list // Language extension
Extending the Parser
Now the parser needs to recognise the new syntax:
let pparams =
between (str_ws "(") (str_ws ")") (sepBy pidentifier_ws (str_ws ",")) let pmethod =
pidentifier_ws .>>. opt pparams |>> (fun (name,ps) -> name, match ps with Some ps -> ps | None -> ) let pfunction =
str_ws1 "Function" >>. pmethod |>> (fun (name,ps) -> Function(name,ps)) let pendfunction =
str_ws "EndFunction" |>> (fun _ -> EndFunction)
The Function keyword expects a method declaration which is composed of an identifier and optional parameters between parentheses.
Calls in expressions are recognized as a single identifier with a list of arguments:
let pcall = pidentifier_ws .>>. ptuple
|>> (fun (name,args) -> Call(name, args))
The code generator now needs to generate methods for both Sub and Function statements, with void and Primitive return values respectively. The generated methods may also have named arguments, passed by value. When an identifier is referenced in a statement the generator checks the method arguments in precedence to global fields. Finally return values are taken from the field with the same name as the method, as is the convention with the Visual Basic series of languages.
Hereâ€™s FizzBuzz in Small Basic utilizing the new extension:
' Returns Modulus Function Modulus(Dividend,Divisor) Modulus = Dividend While Modulus >= Divisor Modulus = Modulus - Divisor EndWhile EndFunction For A = 1 To 100 ' Iterate from 1 to 100 Mod3 = Modulus(A,3) ' A % 3 Mod5 = Modulus(A,5) ' A % 5 If Mod3 = 0 And Mod5 = 0 Then TextWindow.WriteLine("FizzBuzz") ElseIf Mod3 = 0 Then TextWindow.WriteLine("Fizz") ElseIf Mod5 = 0 Then TextWindow.WriteLine("Buzz") Else TextWindow.WriteLine(A) EndIf EndFor
Extending the language touched small parts of the AST, parser and code generation steps. The whole process took only a couple of hours.
With the simple addition of function procedures with arguments and return values, Small Basic starts to approach the functionality of VBScript, and feel more like a grown up language for scripting.
Itâ€™s also starting to feel like the Small Basic AST and parser could be easily extended to support any of the Visual Basic family of languages, from VBScript to VBA to VB.Net.
Whenâ€™s the last time you went for your personal Epic Win? If itâ€™s been a while, no worries. Letâ€™s go big this year.
Iâ€™ll give you the tools.
I realize time and again, that Bruce Lee was so right when he said, â€śTo hell with circumstances; I create opportunities.â€ť Similarly, William B. Sprague told us, â€śDo not wait to strike till the iron is hot; but make it hot by striking.â€ť
And, Peter Drucker said, â€śThe best way to predict the future is to create it.â€ť Similarly, Alan Kay said, "The best way to predict the future is to invent it."
Well then? Game on!
By the way, if youâ€™re not feeling very inspired, check out either my 37 Inspirational Quotes That Will Change Your Life, Motivational Quotes, or my Inspirational Quotes. They are intense, and I bet you can find your favorite three.
As Iâ€™ve been diving deep into goal setting and goal planning, Iâ€™ve put together a set of deep dive posts that will give you a very in-depth look at how to set and achieve any goal you want. Here is my roundup so far:
Hopefully, my posts on goal setting and goal planning save you many hours (if not days, weeks, etc.) of time, effort, and frustration on trying to figure out how to really set and achieve your goals. If you only read one post, at least read Goal Setting vs. Goal Planning because this will put you well ahead of the majority of people who regularly donâ€™t achieve their goals.
In terms of actions, if there is one thing to decide, make it Commit to Your Best Year Ever.
Enjoy and best wishes for your greatest year ever and a powerful 2014.
If you are like me you probably have a long history of projects that are 90% or less done. I’ve had a real problem in my life with finishing what I started.Â But, once I actually started completing the things I started, I learned that the payoff for doing so is huge. In this video, […]
An interview with Bjarte Bogsnes, author of Implementing Beyond Budgeting
The post Beyond Budgeting – 15 Minutes on Air with Bjarte Bogsnes appeared first on NOOP.NL.
There are three keyÂ elements of every project on the planet - Cost, Schedule, and the performance of the product or service produced by the project. Each of these hasÂ drivers. The connections between Cost, Schedule, and Technical Performance are notÂ Iron as suggested in theÂ Iron Triangle of a PMI view of the project. Instead the connections are elastic,Â springy, flexible. But they are connected.
Cost is driven by:
These costs are themselves variable, as a function of the project phase, external forces for labor, materials, and overhead. But the costÂ variable starts with these.
Schedule is driven by:
Technical Performance is driven by:
So What Does All This Mean?
But for project success we need to have several things in place.Â The random behavior has to be knowable. It can't be chaos. If it is chaos, the project will fail, because there is no corrective action.
The three elements need to be known to some degree of confidence.
Do know these to some degree of confidence, you don't know whatÂ DONE looks. The only measure of progress becomes the passage of time and consumption of money. It's unlikely any customer is going to be willing to pay you - at least for very long - to spend their money, without some understand of Cost, Schedule, and the resulting Technical Outcomes.
ÂRelated articles The "Real" Root Cause of IT Project Failure A Fundamental Principle In Managing Uncertainty The 5 P's of Project Management Success Both Aleatory and Epistemic Uncertainty Create Risk Five Core Processes of Project Success
Oliver Erlewein is an automation specialist. He’s respected in the Context-Driven Testing community of New Zealand and has been an agitator pushing back against the ISTQB. After some years of frustration with bad management he finally went independent. Now he’s back to full-time work. He posted the following as a comment:
Starting 2014, I have given up my self-employment and joined a (sort of) start up. I didnâ€™t think I was ever going back to being employed but this was worth it. I have found a company that respects my professionalism and listens to what I say, where I am responsible for what I produce and get the full control of how to go about it. I and the task I do are respected. The word integrity doesnâ€™t get used here but it is a place that actually has oodles of it.
Every now and again I hear the sentence â€śyou are the expert so what do you suggest we do?â€ť or â€śdo what you think is right, you are the expertâ€ť â€¦.and they mean it exactly like that. It makes for a completely different working environment. It motivates, it invigorates and it makes working fun. It puts heaps more pressure and responsibility on me but I am happy as taking that on board because I am convinced that I can do it (even if I still donâ€™t know how right at this moment).
Although this shop is not agile (but more agile than a lot of the shops out there that call themselves agile!) they do something that is one of the main success factors for agile: They re-introduce back the idea of responsibility, professionalism and craftsmanship into (IT) work. And that motivates. I feel like I can call bull**** if it is appropriate to do so or get traction on subjects I think are important.
So although it meant I made a career change away from my original trajectory I made it consciously towards a more ethical work life, where integrity and being the best you can actually counts for something.
Thank you for sharing that with us, Oliver. It goes to show that there are good managers out there who understand craftsmanship and leadership.
Why isnâ€™t systems thinking one of the first techniques any IT change agent reaches for?Â Â I would suggest that it begins with training.Â Most Change Professionals have not been trained in applying systems thinking techniques because it is viewed as an engineering or academic practice. Systems thinking, while applicable to any type of system, has primarily been applied in science, engineering and social sciences. Systems thinking provides a framework for the introduction of lean techniques which have become popular in Â evolving the practices of IT in the context of delivering maximum business value. Lean provides tool and philosophy, and systems thinking provides the breadth of scope to apply those tools. Â Systems thinking provides process improvement with both a scope by defining what a system is and a business related goal for improvement, to improve the delivery of business value.
Affecting processes, systems and the environmental elements that are outside of the change agentâ€™s control is difficult, requiring the development of influence and political capital outside of their comfort zone. For example, in an organization that is delivering a product that requires a hardware and software combination, a change that shortens the length of time needed to deliver the software may not impact the delivery time of the product, if the hardware development does not keep pace. For another example consider a set of process improvements meant to quicken the pace of requirements definition and evolution that feed into a classic stage gate for approval. Changes can be made moot by department boundaries within IT as easy as by processes and systems outside of IT. An example, a few years ago, I observed a group of business analysts who embraced an iterative process for requirements elicitation, but still had to provide a single complete requirements definition document before the project could progress.Â They had not been able to engage the owner of the stage gate process to fashion a scenario in which parts could be passed through the barrier as they were completed. Therefore little of the increase pace was transmitted to the overall process.
Process improvement begins by identifying Â opportunities. In order to use a systems thinking approach to process improvement we need to ensure that the boundary for process improvement is a whole system, a whole value chain and provides the means to affect the output of the whole system. This helps ensure that any changes improve the overall performance of IT. One, simple approach I use to identify systems thinking process improvement opportunities begins by assembling a cross-functional team (or teams, for large supply chain systems) that includes representatives with experience from the whole system – beginning to end.Â This is similar to the process described in our discussion of value chain mapping. I facilitate the team through one or two sessions using a combination of affinity diagramming (brainstorming and mute-grouping) and mind mapping in order to identify the variables impacting the system. Â Affinity diagramming is a technique of driving out and grouping large amounts of data though the use of seed questions and brainstorming, followed by team grouping exercise done without talking.Â Mind mapping is then leveraged to mine the data for non-linear relationships and to prompt for completeness. Â Combining the two techniques (mind mapping and affinity diagramming) with the cross functional team leads to taking a holistic approach to making change. After we drive out the variables, I have the team work through a building a desktop model to identify which variables the team feels will impact the ultimate performance of the system.Â For the variables selected, I ask the team to identify trends underway in these variables and any external trends that impact these trends.Â This generally requires a bit of research and the collection of performance data for the variables. Experimentation is used to determine if the identified variables will have a positive impact on the output of the system being studied.Â Examples of experimentation techniques include building mathematical models and process pilots.
Systems thinking is a powerful concept. However, the breadth of vision required to address even the small process improvements will incent many managers to stay focused on their individual part of the process.Â We have been taught that focusing on specific issues will help us improve what we do over time. Unfortunately, focusing on a narrow view of a complex system rarely provides enough information to affect overall customer experience or satisfaction. When improving development and maintenance processes, what really matters is that we deliver what we promised, when we promised and for what we promised. Then be in a position to do that as many times as required.Â That last requirement means that our interactions, processes and people must be consumed in a holistic and sustainable manner. Building a backlog of process and human debt by focusing steps rather than the whole does not deliver sustainable products.
A few months ago, I’ve met the founders of a mobile game development studio based in San Francisco, CA (they also have teams in Paris and Argentina): PixowlÂ (backed by a lot of tech entrepreneurs)Â Â Not only are they the nicest people I’ve met in a long time but they’re alsoÂ extremely talented! A great combo to start a friendship! Adrien is one of the best mobile developer I know and Laurel is a great artist doing all the illustration for their games (and has a very cool blog showcasing her work)
Today, they have a very successful Minecraft type of game which is doing really good on the Apple Store and they’re working on the second version of their other flagship game: Greedy Grub. Some of you might remember Snake from the early 80′s. This new version of Grub is Snake on mobile steroid!
My kids played the first version of the game and you can bet that when they’ve heard that the second version was on the horizon, they wanted to be involved! They’re the perfect beta testers and provide tons of feedback (Pixowl uses HockeyApp to manage the beta of Grub which has a very nifty feature to add feedback directly in the game. Very handy!)
There is today only one playable level but Grub is already very addictive. I had a glimpse of what’s coming and I think I will soon get rid of candy crush!
If you like games and want to be involved in the feedback process, join the Grub beta today!
Note:Â I have no affiliation with pixowl. I just like games, testing and Adrien makes really good crepes!Get Shareaholic
Adrian Cockcroft on the future of Cloud, Open Source, SaaS and the End of Enterprise Computing:
Most big enterprise companies are actively working on their AWS rollout now. Most of them are also trying to get an in-house cloud to work, with varying amounts of success, but even the best private clouds are still years behind the feature set of public clouds, which is has a big impact on the agility and speed of product development
While the Snowden revelations have tattered the thin veil of trust secreting Big Brother from We the People, they may also be driving a fascinating new tension in architecture choices between Cloud Native (scale-out, IaaS), Amazon Native (rich service dependencies), and Enterprise Native (raw hardware, scale-up).
This tension became evident in a recent HipChat interview where HipChat, makers of an AWS based SaaS chat product, were busy creating an on-premises version of their product that could operate behind the firewall in enterprise datacenters. This is consistent with other products from Atlassian in that they do offer hosted services as well as installable services, but it is also an indication of customer concerns over privacy and security.
The result is a potential shattering of backend architectures into many fragments like we’ve seen on the front-end. On the front-end you can develop for iOS, Android, HTML5, Windows, OSX, and so on. Any choice you make is like declaring for a cold war power in a winner take all battle for your development resources. Unifying this mess has been the refuge of cloud based services over HTTP. Now that safe place is threatened.
To see why...
Many of the challenges in agile and Scrum stem from the idea of the self-organizing team. Of course, many (perhaps most) of the benefits are also the result of self-organizing teams.
One of the questions I get from many leaders is whether it's OK to mandate the team do something like use a particular tool, comply with a coding standard, or such.
Absolutely. A leader in the organization has the right to mandate anything like this. I've even seen a CEO who couldn't tell you a single difference between Java and COBOL who insisted her team use Java. And I supported her in that decision. This was back in 2000 when Sun Microsystems had announced their $100 million "Java Fund" of VC money to companies if they used Java. So this CEO had a reason for her mandate.
So, if you're a leader in your company and have the organizational clout to make dictates: Go ahead.
But, be careful. You can give the team any rule you want, but if you give them one rule too many, they'll shut down. They will go from self-organizing to feeling, "Management just tells us what to do." And there is a very fine here--quite literally one rule too many will push a team over the precipice.
But, I've also seen management mandate things that didn't make sense when the risk of pushing the team out of the realm of self-organization was considered. One PMO insisted all daily scrums occur between 9 AM and noon. This was so the PMO could prepare reports based on the results of the daily scrums. (And, yes, that was a bad idea, too.)
So, when placing a rule on a team, consider it carefully. Any one rule could push them over the edge. It won't necessarily be that rule--in fact, the rule that pushes them over could be a worthwhile rule. It will generally be the overall quantity of the rules that creates the problem.
For each rule, consider whether that rule alone is worth the risk. If it's not, don't put the rule in place. Also, any time you consider adding a rule to a team, see if there's another rule (or constraint on how they work) that you can remove. Otherwise rules build up over time. It's good to periodically review all rules you've placed on teams and see if any have outlived their usefulness.
Next time someone complains that you have made a mistake, tell them that may be a good thing. Because without imperfection, neither you nor I would exist - Stephen Hawking.
Courtesy Don Yeager's daily posts
I have 8,069 contacts in my database now, and 40 different tags. Many of those people are tagged because, for years, I have been keeping track of my connections to other people.
There are Principles, Practices, and Processes of project success. I have a book coming that describes them. These are independent of any method, any domain, any favorite tool, buzz words, or personal paradigm. Much research on Root Causes of project failure have led to these Principles, Practices, and Processes. The Principles don't change, can't change. The Practices need to be tailored to the needs of the project and its paradigm. The Processes are localized.
But around these are 7 Activities of any project, that if not performed in some way, the probability of success is reduced, sometimes to Zero.
Domain and Context
No matter if your building bridges across rivers, a flying machine to Mars, the next anti-virus drug, or writing software using Scrum for your internal web site, these activities must take place in some way.Â
Without the last 4 activities, you're managing the project open loop. This might be OK if your customer doesn't care how much it will cost or how long it will take to finish the defined work. But of they do, you'll need aÂ target cost and aÂ target completion date, the feedback that you're making progress to Â those values. And of course some confidence that thoseÂ targets are credible, their degree of variance, and how they are changing as the project progresses.
So one final comment
When we hear that we don't need to estimate, there is no way to have a closed loop control system. Without on estimate of the cost, schedule, and technical performance goals, the only management control system is open loop. This is unlikley to lead to success for any non-trivial project.Related articles Sources of Variance Evidence of 5 Immutable Principles of Project Success Risk Management for Dummies
We should be guided by theory, not by numbers. – W.E. Deming Many process improvement programs falter when, despite our best efforts, they don’t improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds, the impact overtaken by the inertia of the overall systems. Systems thinking is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events, rather than simply events.Â Systems thinking is all about the big picture. Grasping the big picture is important when approaching any change program.Â It becomes even more critical when the environment you are changing is complex and previous attempts at change have been less than successful. The world that professional developers operate within is complex. Even though the goal of satisfying the projects stakeholders, on the surface, seems so simple. Every element of our work is part of a larger system that visibly and invisibly shapes our individual and organizational opportunities and risks.Â The combination of complexity and the nagging issues that have dogged software-centric product development and maintenance suggest that real innovation will only come through systems thinking. Systems thinking requires thinking broader.Â The Waters Foundation, a group dedicated to applying systems thinking to education, suggests a set of “Habits of a Systems Thinker.” The habits are:
These habits illustrate to really create change you need to take the overall process into account and test all of our assumptions before you can know that your change is effective. An example presented atÂ MITâ€™s System Design and Management (SDM) program on Oct. 22 and 23 exposed the need to address complexity through holistic solutions. A hospital scenario was described in which alarm fatigue has occurred leading to negative patient outcomes.Â Alarm fatigue occurs when health professionals are overwhelmed by monitoring medical devices that provide data and alerts.Â The devices donâ€™t interoperate therefore all of the data and alerts just create noise which can hide real problems.Â Any IT manager that has reviewed multiple monthly project status reports and updates can appreciate how a specific problem signal could be missed and what the consequences might be. Systems thinking applied through the filter of the â€śHabits of a Systems Thinkerâ€ť is tailor-made to help us conceptualize, understand and then address complex problems; to find solutions for problems that seem elusive or that reoccur in an organization. http://www.watersfoundation.org/index.cfm?fuseaction=search.habits  http://web.mit.edu/newsoffice/2011/systems-thinking-conference-1031.html
If any of these items interest you there's a full description of each sponsor below. Please click to read more...