There is a continuing debate - is it process or people? We'll ignore tools for the moment. I made a post on TWTR - process is king - after a lunch time business development meeting about planning for next quarter. In our practice, three essential elements must be in place for our success. There was much discussion about what these elements are. Dozens were listed, many more discussed, but all of them boiled down to these three, with the others finding homes inside these three.
All three are needed, BD without content and delivery doesn't last long. Content without BD never gets started. Delivery without content means we get paid for doing not much of value for the client - we're just labor.
During that lunch, someone turned to me and asked:
What can we identify as a root cause for the majority of project difficulties in our domains (enterprise IT) that our clients will resonante with?
The asker said, you only get to pick one word from people, processes, or tools. PROCESS was my answer.
People are critical to the success of anything on the planet, especially complex, high risk projects. Can't have a hope of success without the right people. But these people need to do the right things, at the right time for the right cost, and do these things right. But the right people have little hope of success, once you move beyond Plato's seven people around the tree - you need some form of process.
Process is the glue that holds the people, business development, delivery, and content together.
It's been suggested ...
... but this ignores the business aspects of business. Without process the people and tools have no way of delivering the value the customer paid for. Agile is a process. I can hear the gnashing of teeth agile is a mind set. BS, agile is a set of processes that allows a mind set to be implemented by the team.
This notion of master / servant is interesting. It's a Ying/Yang view in our domain. Both are needed, where do we start? Spin the Ying / Yang below fast enough and it turns gray. That's how we achieve success. But without process ...
You get it. Process is King. People are King, Tools are Prince's. The you've got it backwards quote is for those 7 people sitting around the tree. A wonderful life. A life much sought after. Works in lots of places, but not all - follow the money to see where the Plato approach to business management is applicable.
Recipes exist to get ideas, not to be followed to the letter†
The recipe for a project is described by its Capabilities. The technical and operational requirements need to support those capabilities, but defining those up front and following them to the letter restricts the creativity of the project team, just like it restricts the creativity of the chef.
† Epicurious web site comment on Vichyssoise recipe
The common practice of starting with requirements leads to the common complaint that requirements change, we don't know what we want yet, our users aren't very good at defining requirements so we'll let them emerge. While these are common, they are usually a symptom of a missing piece of information.
We don't know what capabilities are needed and what is the Concept of Operations that those capabilities will implement, the project as likely failed before it starts. If we do know the Capabilities and the Concept of Operations, we can then measure progress of our work effort, not in the passage or time, consumption of resources (including money), or the production of stories or story points (which are unit-less and therefore pretty much meaningless to those paying the our work), but in Measures of Effectiveness, Measures of Performance, and Technical Performance Measures..
Concept of Operations
Let's start with a formal defininton of the Concept of Operations
What this tells us is that we need to start with what DONE looks like. DONE is not a set of features. DONE is not stories or story points. DONE is not modules, databases, bent metal. DONE is the ability, the capability to do something of value in echnage for the money we've spent.
The assessment of a capability is it's Measure of Effectiveness. These are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. We need to define these upfront. The Measures of Effectiveness:
They are not emergement. They are descriptions of success. When we treat them as emergent, our project is chasing a moving target and is headed to the ditch.
Next are Measures of Performance. They characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. The Measures of Performance are:
Next comes the Technical Performance Measures. These are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. The Technical Performance Measures:
Notice we have not mentioned coding, development methods like Scrum or XP, teams, paired programming of anything to so with building code. With these items in place, all those activities have no reason for being, other than to consume money and pass time. None of those items having anything with moving the project toward DONE, other spend money and pass time. Oh, you'll get a pile of stories implemented. Are they the right stories? How would you know. You'll perform lots of Test Driven Design. Is is the right design. How would you know?
Oh your customer is going to prioritize those stories and features. How are they going to know in the absence of knowing what DONE looks like.
Capabilities Based Planning
This has been presentde before, but now it has a reason - the Concept of Operations.
Capabilities based planning (v2) from Glen Alleman With the ConOps and CBP, we now have what we need to assess the development processes.
We Know the Answer To That Rights?
Much of the discussion around making improvements in processes fails to address the governance aspects of a business or organization. Instead it focuses on the personal aspects. Agile development of a software team, without the corporate impacts. The desire to stop doing something without an actual replacement, under the guise of we're exploring. Our the mention of the term intent of the commander without understanding that filling out that intent requires complete capabilities to act in in the absence of direct supervision.
My project management maturity was changed forever at Rocky Flats, under the management of senior leaders with experience and skill formed in the US Navy. The book Making the Impossible Possible is the story of that project and the learnings that can be applied in any high risk, complex, high reward domain.
Making the impossible possible from Glen Alleman The term Intent of the Commander is actualized in the concept of the Plan of the Day. Here's an actual plan of the day for shipboard life. This notion of plan of the day was applied late in the Rocky Flats program. Before that we had Plan of the Week and then Plan of the Month. The approach is very simple. What do we plan to get done at the end of this period (day, week, month? Write that down, establish some measures of performance and effectiveness for those ourcomes. Measure them, take corrective actions if they don't match the expectations. Repeat until done.
Did you read When Did You Last “Shop” Your Candidate Experience? See the common complaints from candidates:
You don’t have to vie for a “Best Place to Work” award or a candidate experience award, or any award at all. You need to be authentic. That’s all.
I don’t buy their solutions. (No surprise there, eh?) In fact, I think their standard interview questions stink. If you read Hiring Geeks That Fit (as an interviewer), I have better questions for you to ask. If you are a candidate, I have better ways to answer these questions in Manage Your Job Search.
Here’s an example: they suggest you ask, “Where do you want to be in 5 years?” Well, I don’t know any company willing to commit to anyone for 5 years. That’s an irrelevant question. Instead, ask something like this, “Tell me about a recent time when you learned something and applied that learning at work?” Or, “Tell me about a time you wanted a promotion. What did you do to earn it?” Or, “Tell me about a recent time you learned a problem your manager needed to have solved. What did you do?”
As a candidate, you can turn this around, and say, “Let me ask you instead, what objectives do you have for this position in the next 3 months, 6 months, and year, or even longer? I can provide you a better answer based on what I’ve done in the past and make it relevant to the job.” Then you give a behavior-description answer.
Remember, you represent your company when you start the hiring process. You represent your culture as soon as you start hiring, from the ad to the initial candidate encounter. What does your interviewing say about you?
When we hear about all the methods of managing projects, the PMI Body of Knowledge, PRINCE2, home grown and commercial solutions - always look at them in the light of these 5 Immutable Principles and the 5 Practices then implement the principles.
Principles and Practices of Performance-Based Project Management® from Glen Alleman
If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want (working software all the time and expose the interdependencies), provide training or whatever other resources they need, you are likely to get what you want.
That’s why I wrote Design Your Agile Project, Part 1 for teams who are collocated, and can use any approach to agile. Design Your Agile Project, Part 2 is for teams who have many challenges, but are collocated, and can work through those challenges. Design Your Agile Project, Part 3 is for teams who are geographically distributed and have to think about what to do.
In the program, what you need is for each team to deliver, all the time. The program wants as close to continuous delivery as possible. You can reduce the interdependencies—or plan for them. You can certainly expose them.Feedback is Necessary
Did you see Jason Yip’s tweet (@jchyip) the other day, where he quoted this, “”Large organizations…lose their resilience simply because the feedback mechanisms…have too many layers of delay and distortion.”
This is why you cannot standardize on anything for any team in a program. Why? A program needs resilience. It needs to be able to release early and often. Just because it’s a program does not mean it does not need to be able to obtain feedback.
Each team must know the principles:
Teams use agile and lean principles. Management treats the people on the teams as if they are adults. The teams look at their own issues and design their own approach to agile/lean, always keeping in mind the idea that they need to deliver early and often.
Now, let’s talk about what happens when you want to meld these teams into a program.Each Team is the Heart of the Program
You might think that things roll down from the program manager or the core team. Not in my world. This is where each team’s autonomy, each team’s ability to make its own decisions about how it implements its approach to agile or lean is key.
The teams are the heart of the program. All of the teams: the core team, the technical teams, the teams that the core team represents.
This is a change from traditional process thinking. It’s a change from traditional program management thinking. This kind of thinking requires that the teams know how to do agile already, and are new to the program, not to agile. This kind of thinking also means that the program manager is a servant leader.
In a program, you will have interdependencies. You want to minimize them. How do you do that? By reducing batch size, the size of each feature. By coordinating the features with a program roadmap. And, by looking at the value of each feature, not its cost (estimate).
That means the teams need to become good at delivering, not estimating. It also means the product owners need to become very good at creating ranked backlogs for the teams, and changing them. It means that the program needs a roadmap that can and does change.
Remember, agile is about the ability to change, because the teams get to done at regular intervals, whether those intervals are iterations or because the teams work in flow.What If the Teams are New to Agile?
What if you want to have a program with teams that are new to agile or lean? You can do anything on your program. You need to assess your risks. Let’s look at the Cynefin framework to see where your risks might place you, if your teams are new to agile.
If your teams are new to agile, and they are all in one physical location, and they know the domain of the product under development, i.e. you are only changing how they are developing, maybe you are just in the Complex part of the framework. You are changing the culture of the program.
However, if you have new-to-agile teams, who don’t know the product domain, who are geographically distributed or dispersed from one another, and you want to transition to agile, do you see that you might be in the Chaotic part of the framework? That you have no way of knowing the risks?
That is much more difficult.
Let me provide you an example. Imagine that you are working with developers in Europe who have a 15-person development team. They have only programmers on their team. They have never worked with testers. Why? They have never seen the need to do so. They have been successful, according to them, up until now.
You are in New York, where the product management is. You know the product domain. The developers? Well, maybe not so much.
Several years ago, I consulted to a company that had this precise organization. They were going to “revolutionize aerospace.” Only the product managers understood the aerospace information. The developers had no domain expertise and they were several timezones away. The developers had worked together before, but had never worked with testers. They had never seen the need. They had never worked on a regulated product before.
When I suggested they had “unknowable unknowns,” and that their risks were higher than they thought they had, the senior management laughed at me. I told them yes, agile was fine, but I thought they should use one- or two-week iterations with kanban boards to expose their bottlenecks.
They ignored my advice. The company went with four-week iterations, spent a pile of money, had no product to show after 18 months. Oh, the developers bandied words such as “refactoring” and “TDD” and “BDD.” What they did was BDUF (Big Design Up Front) because they had no idea what they were doing. The company went under.
What do you do when not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change?
Don’t panic! You work in ways to reduce your risk.
Stay tuned for Part 5.
In a recent post titled #NoEstimates - Really? there was an interesting comment.
Clearly, the business value of any feature or project can not be known with much certainty in advance of it being implemented. Still, for the purpose of keeping the analysis simple for now, let’s table this issue for a bit.
This is not the case in a governance based organization or a Capabilities Based Planning organization, where the "valuation" of the resulting product, service, or purchased or built product is part of the planning process.
It's a "build to valuation"
Knowing - to some probabilistic level of confidence - what business value or mission fulfillment the project or product will produce is the core of any decision making process. Knowing the cost of the value is about making decisions, analysis of alterntaives, or assessing the trade space.
With the "estimated" value and the "estimated" cost for that value, a decision can be made in what is called "analysis of alternatives" in our software intensive domain.
Only by having both estimates - value and cost of acheiving that value, their most likely numbers and the probabilistic range of those numbers (measured usually in dollars), can we make that "analysis of alternatives," or "trade space" needed to Govern both the business and the project and products that enable the business to meet its goals.
So there are popular myths around the estimating of cost and value discussion, and a few that are just flat out bogus:
I am very pleased to let you all know that my new book, Double the Love: 11 Secrets for Cultivating Highly Accountable and Engaged Teams, is available on Amazon.com. Right now, the paperback version is available. The e-book format will be on amazon within a week.
I hope you will check it out and can't wait to hear your feedback. The book features a model that I have been using with leaders and groups for several years. It tends to resonate with folks, so I hope the same is true for you.
A bunch of fabulous people reviewed the pre-production version of the book and offered their endorsements. Here's what they said (listed in alphabetical order):
“Reading this book is like having Lisa sitting next to you sharing her wisdom and whispering her secrets in your ear. Her intriguing style will captivate you from the start; lead you through a model, practical advice, and workshop activities; and leave you wondering how quickly you can implement one of her brilliant ideas. Lisa is the consummate story teller who combines real-world recommendations with wit and humor, leaving you laughing, reflecting, and wanting more.” Elaine Biech author, The Business of Consulting and editor, The ASTD Leadership Handbook
“If you want better business results, open your mind, a good bottle of red, and read Double the Love. Author Lisa guides with her unique mix of wit, big experience and perspective in a way that that challenges leaders beliefs and actions about accountability and the holy grail of discretionary effort.” Randy Boek, Professional Outsider and President, Route Two
“Extra love doesn't cost you anything, so why don't more leaders give it away? Double the Love will give you the must-have tools to deliver better results, get promoted faster, and inspire others to do it, too!“ Cory Bouck, Director of Organizational Development & Learning at Johnsonville Sausage; author of The Lens of Leadership: Being the Leader Others WANT to Follow
“Another amazing book! I absolutely love the fact that I can grab it, apply the tools and be inspired to make my work world a better place. Double the Love is engaging me and making me feel empowered! I’m printing the page on “20 Ways to Be an Advocate” because they are great reminders of how easy it is to make someone’s day and build a relationship.” Johna Campbell, Senior Manager of HR, Kollmorgen
“If you want to transform your teams and get them to perform better, you need to know the secret. If you REALLY want your teams to perform better, you'll need the secrets in 2 areas: accountability and engagement. Thankfully, this book focuses on simple (though not always easy) ways you can double your love and thus double (or MORE) your love, er, results. And not only can you learn the secrets - you can learn how to actually use them - to do more, and, most importantly, to maximize the performance of your team. Believe it: You CAN double the love!” Phil Gerbyshak, author, speaker and VP of Sales and Marketing for Advisology
“With her usual playful style, Lisa has once again delivered an accessible yet hard-hitting primer on some of the biggest challenges facing leaders today. Striking the right balance between accountability and engagement is an art form. The structure of the book makes it a thought-provoking primer on the theory behind her 11 secrets for building strong teams, and also a very practical field guide for how to bring these ideas to life. I already found three things I'm planning to try at work on Monday!” Kathleen Goodman, Director, Strategy, Planning and Management at Bill & Melinda Gates Foundation
"When it comes to understanding what makes people feel truly engaged in their work, no one cuts through the clutter of organizational improvement processes, tools, and other assorted junk, and gets quicker to the heart of what really matters than Lisa Haneberg. In her new book Double the Love, Lisa provides a set of simple secrets that will help you more effectively develop highly accountable and engaged teams within your organization." Chris Grams, President, New Kind
“In Double The Love, Lisa Haneberg has written a book that redefines accountability & engagement systems, for each of us who need to be able to “bring out the very best in people”. She also includes assessments, exercises and other tools that are guaranteed to move you along the continuum to more effective leadership, wherever you may be today. The content & her writing style, make it a must read. “Brenda Gumbs, EVP Human Resources, Perfetti Van Melle, USA, Inc.
"Zounds! After breakthroughs, the "Secrets" were always right there in our face. Leadership that is intentional, persistent, yet humble and lovingly refocusing the "me" to the "we" - sounds like the team I want to be on." Jeff Krida, Vice Chairman, Co-Founder American Queen Steamboat Company
“Lisa brings a wealth of personal experience and knowledge to the table in this book. A refreshing and honest look at improving dynamics within your team that I highly recommend to anyone hoping to bring a new level of excellence to the workplace.” David Loewe, Chief Executive Officer, Seattle Humane Society
“Lisa, this is truly “FANTASTIC.” Engagement really is about making work meaningful and purposeful.” Lloyd Lopez - Supervisor, Client Services, Quest Diagnostics
“Accountability is one of the most ‘lip serviced’ words on the planet, but Lisa changes the game of accountability in Double the Love. You want a powerful team? You want to be a great leader? Read this book and change your world.” Dwayne Melancon, Chief Technology Officer, Tripwire, Inc. & Author, GenuineCuriosity.com
“Outstanding! A terrific fun to read book that provides clear steps for organizational excellence.” Martin D. Moll, Practice Leader, AKT CPAs and Business Consultants
“This terrific book brings together the intentionality of good design with the science of motivation to help leaders create better workplaces. The synergy is extraordinary.” Daniel Pink, author of DRIVE and A WHOLE NEW MIND
“Double The Love” is a treasure trove of transformative ideas, secrets and wisdom on how to build an engaged and accountable workforce. Wish I had this book early on when I built my first team! Tanmay Vora, Author, Blogger and Improvement Consultant at QAspire.com
“This isn’t for a blurb in the book, but I just wanted to tell you that I can’t wait for your book to come out. I so need this information right now.” Sharon Walling
“Those who treasure Lisa’s practical, humorous and popular books will love her mind-bending secrets that lead people just as they are. Expect to spot cranky, courageous and creative under refreshing new lights. Leadership words of wisdom come chalk full of passion and with the kind of tools and skills workers crave. Lisa Haneberg’s clearly at her best in this book!” Ellen Weber (PhD) directs innovation at the Mita International Brain Center.
“Lisa has released the secrets on the push and pull of engagement and accountability at work. She offers stories, guidance, and insights to find the healthy push and pull of work to "double the love" as we race towards a 2020 workplace. You will love this book as you love the results and relationship building it offers you at work.” David Zinger, David Zinger Associates, Founder and Host of 6300-member Employee Engagement Network.
Thanks so much for these kind words! Makes me feel doubly loved.
Speaking on Techncial Performance Measures and conducting workshop on same topic with Mr. Kranz and Tom Coonce of IDA.
The right question for any suggested improvement, change, or suggesting we stop doing that need to produce an answer to ...
Does this suggestion increase the probability of project success?
This means tracing the suggestion to the outcome of the project being better, faster, cheaper, or some other tangible measure of improvement.
What does project success look like?
The delivery of agreed-upon capability within established resource constriants, e.g. funding, schedule, facilities.
Five factors are used to assess the success
So Now What?
When we hear about something new, anything new, how can we test it that suggestion against business needs, mission needs, governance, or strategy. This starts with establishing the domain in which the suggestion might possibly work. Then proposing the framework in which it has worked or might work. Then a proposed way to assess the possible benefits of performing the sugegsted solution.
Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand".
Mary Doria Russell
It is that difference that is needed to assess when a idea passes the smell test.
These participants play off each other, react to emergent streams of melody, contribute their own special talent to the music and pretty much work in a a self directed manner over the course of the performance.
While I'm not a fan of analogies, this is a useful one for the purpose here. There are certainly domains where the Jazz analogy describes what is going on in the trio in the picture to the left.
But what about other music? Music that is just as creative, just as moving, just as impactful to the listener. Beethoven's Ninth Symphony's Ode to Joy with the poem from Friedrich Schiller 1785 work is an example.
Words that have moved nations and populations. Following Beethoven's Ninth was a movie we saw over the weekend that described this result.
In the Ninth, each performer has a score to follow, led by the conductor, but also by the concert master and the senior players in each section. The vocals are also led by a senior performer.
In the software business there are likely similar domains and projects. Ones that can be improvised and ones that require conductors, a concert master, and players who follow the score.
In both cases - and this is where the analogy falls apart - is the players are highly skilled, experienced in the art, having played the basic themes 1,000 of times over before improvising or following the score.
The jazz performance is not made up as it goes. OK, fusion is, but that crap makes my head hurt. Melodies, rules for cords are practiced for 10,000 hours (Gladwell), relationships between the players have magical connections not available to mere mortals. The Jazz Trio and the Berlin Philharmonic are populated with highly skilled and experienced professionals. We've all heard our children play in the school band and know what that sounds like. All the platitudes in the world about agile axioms are of no worth without the necessary capabilities to actually get the work done properly.
Applying the notion that agile software development is like jazz makes as much sense as saying I can sit in the 3rd chair of the trombone section (my high school band position) and play my contribution to Beethoven's Ninth without a Curtis Institute degree in performance and 10 years experience (my aunt was a professional pianist in the late 1950's from Curtis).
It's not gonna happen - in both analogies - without the prerequisites of professional performance capabilities. Otherwise the result sounds like we're back in High School Music class with Mr. Meach (my teacher).
So how long will it take us to be capable performing to a level needed to not smell like we're high school kids in the marching band? I don't know let's make an estimate.Related articles Analogies, the Good, the Bad, and the Ugly The "Real" Root Cause of IT Project Failure
Today’s job search trap is something we can all identify with: biting off a big chunk of work and not getting it to done fast enough. I suspect we have all been there and done that!
How do you avoid this particular trap? I like to assess each of my tasks on my board and ask, “Do any of these look as if they will be more than two hours long?”
Two hours is not a lot of time. Two hours is long enough for me to make progress on something and get it to done. It’s also long enough that I’m likely to complete it. And that’s the key.
You know what the problems are in a job search: you have interruptions, such as phone calls; your family needs you to drive them or do laundry or something else; you want a perfect resume. The list goes on and on.
Instead, think of ways to make your tasks smaller. Here are some approaches:
Tomorrow is the last day of the Manage Your Job Search launch. Yes, I ran the launch Wednesday-Wednesday. That’s one of the tips in Manage Your Job Search, to start your week on a Wednesday. Today is the last conference call about tips and traps. I’ll do a quick intro and answer your questions. Join me?
P.S. I just fixed the title of this post. I misspelled the too, as in too much to do. Oopsie!
There is a continuing discussion in the agile community about delivering value in the order set by the customer. Along with this discussion is the use of the word DONE. A popular phrase is no requirement or piece of software can be considered DONE until it is put to use.
This is a software developers point of view of course. But there is another view of software based products. It starts with the Measures of Effectiveness for the resulting product. These Measures of Effectiveness are:
Operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in an operation environment, under specific conditions.
This measure of DONE is not directly related to code, testing, requirements or anything like that. It is related to how Effective the software is in delivering the capabilities needed to fulfill the mission or business case.
The individual requirements and pieces of code that implement them can be - or should be - traceable to these capabilities. For each Measure of Effectiveness, we then need a Measure of Performance. These measures characterise:
The functional or physical attributes relating to the system's operation, measured or estimated under specific conditions.
These are also not direclty related to producing code, running tests, or other direct software activities.
All the software design, testing, integration, etc. supports the creation of the ability to produce these Measures of Performance and Effectiveness. For the end user, all the development work is behind the scenes. What the customer actually bought was the ability to do something useful. To put a capability of the software system to work accomplishing a business need. Make money with this capability of course.
So What Does All This Mean?
It means that if you start at the bottom - with the software development processes - you're likley not going to see what the real picture is. This picture is that the customer paid for capabilities, measured in units of effectiveness and performance.
When we start with methods, paradigms, even cockamamie ones like not estimating the cost of the work effort needed to produce the capabilities, we loose the connection to why we are here. We are here to produce software that provides a capability. Likely more than one capability.
So when we hear words like - we can manage projects without knowing the cost or we'll let the requirements emerge, or the customer doesn't really know what they want, so we'll get started so they can decide along the way, ask how you are going to recognize DONE, before running out of time and money?
How Do We Discover the Needed Capabilities?
Once we've decided that capabilities are in fact the place to start, how are they gathered. Here's the top level set of activities.
Once we have these, we can start to elicit the technical and operational requirements that will fullfill these capabilities.
These requirements can be emergent, they can evolve, they can be elicited incrementally and iteratively. But what ever way to appear they need to have a home. They need a reason for being here. They need to enable a capability to be available to the user.
I will be doing a webinar for BrightTALK on Accountability and Engagement, and helping leaders learn how to optimize both, on this Thursday, April 17th, at noon Eastern. It will be just 45 minutes and is free to attend. You can use this link to register.
During this webinar, I will share a model of accountability and engagement and discuss three of the 11 secrets I have outlined in my upcoming book, Double the Love: 11 Secrets to Cultivating Highly Accountable and Engaged Teams. The target audience for this webinar is HR, Training, OD, and Leaders (you!).
And for my HR/Training/OD pals, my webinar is part of a series called the HR Management Summit - check out all the free webinars here.
I hope you can attend the webinar - I just finished the slide deck and I think you will enjoy it and find it insanely useful.
Here’s another job search trap: you think you can network by going to professional group meetings, mashups, informational lunches, and other kinds of what I call “background networking.”
You need to do this kind of networking to expand you network. But it won’t get you a job. It will keep you unemployed.
You need to also create a target list of companies, companies you want to work at. Not types of companies. Real companies, with real names, on a real list. This takes research.
Once you have your target list, you also need to have your marketing spiel (which I describe in Manage Your Job Search), and then you can decide how to find someone at one of your target companies every single week.
If you expand your background networking every week, chances are good you know someone who knows someone at your target company. Maybe you even know someone at your target company! But, if you haven’t defined your target list, you don’t know what you are looking for. It’s a problem.
You do need to go to meetings. You do need to have informational interviews. You need to keep thinking about where you are focusing your networking efforts.
Background networking, by itself, is insufficient. Add target networking to it? Now you have a winning combination.
There are two more days of the Manage Your Job Search launch. I’m hosting conference calls this week. Today’s, April 14, is about networking basics. Tomorrow’s is tips and traps. I’ll do a quick intro and answer your questions. Join me?
Ninety percent of everything is crud - Theodore SturgeonModels ...
When I hear the phrase we're exploring I'm reminded that in fact many who explore without a plan, measures of their progress progress against this plan, a risk management Plan-B for getting home when things go wrong, and without insufficient resources to survive the trip - come home empty handed or many time don't come home at all. Exploring without these items is called wandering around in the wilderness looking for something to eat.
Here's a simple tale about an actual explorer, Ernest Shackleton, who experienced failure and near death on their first expedition to the South Pole (ADM Scott), that informed his attempt the reach the Pole a second time, only to experience failure again. In the first example prepartion was weak, management inconsistent, and lacking an actual strategy, no Plan-B. The second attempt, without Scott, was well planned, well provisioned, well staffed. When trouble started, Plan-B and then Plan-C were put in place and executed.
What's the Point About Managing Projects? So when we hear we're exploring and there is no destination in mind, or named problem to be solved, or even a description of possible root causes of the un-named problem, remember Shackleton's first trip and Scott's mismanagement of that exploration. On the second trip Shackleton had estimated what he would need, what route he would take, what skills his crew needed, what Plan-B would be, and even Plan-C when that didn't work, and most of all he estimated the probability of success to be high enough it was worth the risk to reach the South Pole and return to tell about it. The Polar expedition for Shackleton was a project, planned and executed with credible estimates of every step along the way, including the possibilities hat everything could go wrong and it did. Through is leadership, they lived to tell about it. Related articles Performance-Based Project Management(sm) Released Agile as a Systems Engineering Paradigm 1909 - Ernest Shackleton, leading the Nimrod Expedition to the South Pole, plants the British flag 97 miles (156 km) from the South Pole, the furthest anyone had ever reached at that time. Black Swans and "They Never Saw It Coming" 3 Impediments To Actual Improvement in the Presence of Dysfunction
In the discussions around #NoEstimates, it's finally dawned on me - after walking the book shelf in the office - the conversation is split across a chasm. Governance based organizations and non-governance based organizations.
Same is the case for product development organizaitons. Those producing a software product for sale or providing a service in exchange for money. There are governance based product organizations and non-governance based product organizations.
I can't say how those are differentiated, but there is broad research on the top of governance and business success using IT. The book on the left is a start. In this book there is a study of 300 enterprises around the world, with the following...
Companies with effective IT governance have profits that are 20% higher than other companies pursuing similar strategies. One viable explanation for this differential is that IT governance specifies accountabilities for IT-related business outcomes and helps companies align their IT investments with their business priorities. But IT governance is a mystery to key decision makers at most companies. Our research indicates that, on average, only 38% of senior managers in a company know how IT is governed. Ignorance is not bliss. In our research senior management awareness of IT governance processes proved to be the single best indicator of governance effectiveness with top performing firms having 60, 70 or 80% of senior executives aware of how IT is governed. Taking the time at senior management levels to design, implement, and communicate IT governance processes is worth the trouble—it pays off.
IT Governance is a decision rights and accountability framework for encouraging desirable behaviours in the use of IT. And I'd add the creation of IT, IT products, and IT services. Since IT is a broad domain, let's exclude development effort for things like games, phone apps, plugins. and in general items that have low value at risk. This doesn't mean they don't have high revenue, but the investment value is low. So when they don't produce their desired beneficial outcome, the degree of loss is low as well.
Asessment of IT Governance focuses on four objectives:
In all four, Weill and Ross provide guidance for assessing the capabilities of IT. In all four Cost is considered a critical success factor.
Without knowing the cost of a decision, the choices presented by that decision cannot be assessed. So when we hear #NoEstimates is about making decisions, ask of those decisions are being made in a governance based organization?
Then ask the question who has the decision rights to make those decisions? Who has the need to know the cost of the value produced by the firm in exchange for that cost. The developers, the management of the development team, the business management of the firm, the customers of the firm?
The three dependent variables of all projects are schedule, cost, and technical perfomance of produced capabilities (this is a wrapper word for everything NOT time and cost). The value at risk is a good starting point for deciding to apply governance processes or not. If you fix one of these variables - say budget (which is a place holder for cost until the actuals arrive), then the other two (time and technical) are now free to vary. Estimating their behaviour will be needed to assure the ROI meets the business goals. In the governance paradigm, these three dependent variables are part of the decision making process. Not knowing one of more puts at risk the value produced by the project or work effort. It's this value at risk that is the key to determining why, how, and when to estimate.
What are you willing to loose (risk) if you don't need to know when you'll be done, or what you'll be able to produce on a planned day, or what that will cost, or determine if the ROI (return on investment), ROA (return on asset value), or ROE (return on equity) to some level of confidence to support your decision making - then estimating is a waste of time.
If on the other hand, the firm or customers you work for writing software in exchange for money have an interest in knowing any or all of those answers to support their decision making, you'll likley going to have to estimate, time, cost, produced capabilities to answer their questions.
It's not about you (the consumer of money). To find out who, follow the money, they'll tell you if they need an estimate or not.Related articles Back To The Future Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Danger Will Robinson Some more answers to the estimating questions Capabilties Based Planning, Use Cases, and Agile The Value of Making An Estimate