Project Management

30% Time Wasted Looking for Data, 50% Success Rate Finding It

A fact that Kim Robertson , the author of over 100 discipline specific training packages, 3 fiction books and articles for CM Trends and various other trade publications from industrial arts to Configuration Management, stated in a recent podcast.

His latest collaboration Configuration Management: Theory, Practice, and Application is

Excerpt from the Podcast:

Joe:   One of the parts that jumped out of me was some of the statements right away that you made in the heading of the poor handling of data. I think you mentioned that 30% of the knowledge worker’s times are used for looking for data and even at that, there’s only a 50% success rate.

Kim:   Yes, that’s a problem across industry. That one actually came from another book that I got that information from. Basically, we don’t have the data linked. So for example, if you have a subcontract; with the subcontract you have a purchase order, you have a statement of work, you may have some specifications. After that, you have data that they’re going to send it to you which is usually supply chain data lists. Nobody is hooking those together within their product data management or product life cycle management systems. They can tell you every piece part and who the vendor was that goes into the buildup of the final item, but they can’t tell you where the data was, what the receiving’s factual report actually said about the information or much else. That’s very bad when you’re trying to do any type of quality assessment on why things aren’t working the way you thought they would within test before you field something. Or in the case of things like the switch the GM had, where did you go wrong with that piece of it and basically that gets back to one of the premises that if two things don’t look the same, aren’t of the same quality, don’t look alike, don’t keep the same number and we find that that goes on quite a bit. There have been cases of airlines where it’s time to replace an engine and they order a new engine for the jet aircraft, the engine shows up and it doesn’t fit on the wing because they made a change, but they didn’t change the top assembly number.

We have all of those types of activities that we need to take a look at and integrate them together somehow. We have this problem with the Lean-type activities as well. Lean Six Sigma is something that is very popular right now. Lean Six Sigma I believe says you’re going to have two bad parts after every million or so. A couple of years ago, there was a company that ordered a couple million resistors all of the same value from another company and they had a Lean Six Sigma requirement and the company they’d ordered from, the supplier kept saying, we’re going to have to hold off a couple weeks, giving you this last supply data management report. I said well okay, and so then eventually the report came in and there was a shipment of resistors and there were two resistors typed to this note on top of it saying, we didn’t know why you wanted two bad resistors, but it took us eight weeks to find them, since they were working at an Eight Sigma level. So a lot of that, you have to know what your suppliers are capable of before you let your requirements on them because otherwise you may be forcing them to do work and costing you money that you don’t have to spend.

Joe:  I think about the data, I think that the inaccuracies that you point out in the data and the lack of cross-references and coordination between all these data, and from a layman’s standpoint it sounds like here we are back to this old file cabinet thing that 80 to 90% of whatever we put in the file cabinet, we never retrieve again. What we did retrieve, a lot of it was inaccurate and though that was in the paper world, is data much better?

Kim:   One advantage you had with the paper world was at least you could retrieve it. What we see a lot with the information technology, these activities are that some people make uninformed decisions that the data isn’t required, and so they may dispose of it. We’ve had some cases where I was involved in a program where the decision was made, we’re just paying too much for backing up servers and so we’re not going to back anything after three months. We’ll backup nightly, we’ll back up weekly; we’ll backup monthly. We’ll save three monthlies and then when we save the fourth; we’ll throw the first one away. Lo and behold an entire program’s worth of data went missing and it happened four months or more before it was discovered and the customer was asking questions because the units were still on the field, and nobody could find any of the information. As far as data retention itself goes, I don’t think that we’re much better because the IT organizations and the programmatic aren’t really communicating or understanding if they are talking what the actual requirements are and often its retention for 10 years after disposal of the last unit which with an automobile maybe 40 years from now. On a space asset, some of them would have been up there 35 years. Voyagers have been up there almost 30 years I believe, and it is still going. All of that data is still being retained some place.

Which brings us to a secondary problem is what happens, because the computers are going and involving so quickly. You’re talking about possibly having quantum computers now which would give us something besides buying a recode because you’d end up with 16 possible states for an answer making things not black and white or ones and zeros but shades of gray or Technicolor if you would. So we have some of the missions where we actually archive the computers, the operating systems, the software and everything else because 15 years from now, all of that evolve and there will be no way to actually communicate with a spacecraft that was in orbit. The same thing is going on, on the ground. The last launch of the space transportation system, they were sourcing all 86 boards off of eBay to keep the systems running in order to make that last launch because the hardware was so old, and we have the same thing going on with the data. How do you keep it current and we’ve been struggling with that for a long time. The portable data format or PDF has been a great help with that because PowerPoint and those types of things, when you move them from one server to a lesser cost, storage type of retention sometimes get corrupted and you can’t ever retrieve them again, but PDF’s still seem to be good.

Joe: Configuration management is supposed to help us with all these problems and to me, it sounds good but how does configuration management or what are the keys there to make all these things right as we just talked about?…….

Related Podcast or Transcription: Configuration Management

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Configuration Management Tales #2

Kim Robertson is the author of over 100 discipline specific training packages, 3 fiction books and articles for CM Trends and various other trade publications from industrial arts to Configuration Management. His latest collaboration Configuration Management: Theory, Practice, and Application is available for pre-order on Contact Kim through LinkedIn or Kim.Robertsonatvaluetransformdotcom.Kim Robertson

His interests in education and training development started in his teens. He is a NDIA certified Configuration Manager with degrees from Westminster College in Mathematics and Physical Sciences and a Master’s degree from the University of Phoenix in Organizational Management with a sub-specialty of Government Contracts.

I enjoyed Kim’s storytelling so much that I left the time get out of hand. As a result, Kim talked himself in to a two part episode. The is second podcast, the first podcast is Configuration Management Tales #1.

Should You Use More Than One Project Methodology?

In the project world, seldom, if ever, do you see any discussion about using multiple project methodologies. When you think about it, is every methodology good at enterprise management? Is every methodology scalable? VSM

When we think about the variety of projects that are there for our use, Waterfall, Scrum, Agile, Kanban, and a host of others, why should we be limited to one? Even in a single project methodology, like Kanban, Corey Ladas made the claim in Srumban that you never create the same Kanban board twice. Jim Benson of personal Kanban fame talks about a Kanban Board Walks through an organization and how at each Kanban Board they were all slightly different. This exemplifies the idea that you have to make the process your own but does it enforce that the methodology should also be your own for better results?

I am going to pick on Kanban, even though it is my favorite project methodology. I have listen to arguments in the past from Scrum people that Kanban was not scalable but is the Scrum of Scrum really best suited for managing Scrums?

A project is created to reduce uncertainty and to carry out a mission. Most of this believe by following a project methodology that we reduce this uncertainty and, of course, allows us to execute a mission. I have been part of a few unsuccessful projects before, and a few might have failed because of poor planning or even the methodology. However, the ones that stand out, the tough ones that were delivered on time and on budget seem to have succeeded because of the people involved not the methodology. Even more often it was because of the project lead.

Should a project lead determine the methodology for a project as part of the project requirements or scope statement? A lack of familiarity or maturity of the group may dictate a different way. We may want more of a time base iteration or even a resource driven project. In most businesses, we have a variety of reasons for a different project methodology. We need to ask ourselves just a few questions like this:

  1. What is the project experience of the project members?
  2. Are all project members familiar with the current technology?
  3. Does it include Customers?
  4. What type of project is it?
    • Low or high tech?
    • Strategic or operational?
    • Consumer, Public, Government?
    • Production, Operations, Knowledge Work?
    • Regular time, Fast Paced?
    • Critical, Non-Critical?
  5. What is the breadth of the project?
  6. Is the project simple or complex?

Are present methodologies adaptable enough? Should we even expect that or want that? Should we always be trying to create a consistent methodology for everything and everyone? Or, should project planning be looking more at different methodologies than it does?

P.S. In the sales and marketing world, do you consider the typical Sales Funnel as sort of a project plan? Does one size fit all?


When Do You Use Scrum Versus Waterfall

Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management. He holds multiple degrees, seven patents, has authored and contributed to numerous books and magazine articles as well as teaching and speaker at technical schools, universities and conferences on a variety of business and product development topics. Jon is my podcast guest tomorrow and below is an excerpt from the podcast.

Joe Dager:   When would you recommend that type of — when you use Scrum versus let’s say a Waterfall, is there a good rule of thumb where one fits? Not everything should be done in Scrum, should it?

Jon Q:   I think you’re right there. I would say definitely not everything is Scrum, just like definitely not everything is Waterfall. And it kind of irks me sometimes when I read that on blogs or hear people say that Scrum is the bomb or the thing to replace Waterfall. It’s not true, no more than Waterfall could replace Agile. There are certain attributes of your organization and your project that tell you whether you should use Agile or conventional. For example, if I’m working an automotive project that has a lot of tie-ins with heavy capital and manufacturing, distributed all over the world and regulations, I probably would consider that I might consider using a Waterfall approach. The logistics around that are kind of high, the regulations on those are very specific, and proof of conformance to those regulations are very specific, and if something goes wrong, you’re going to have to have some track record to traceability, and that might be a little difficult to come by in an Agile incarnation. If you have a team that’s a bunch of experts, they’re very seasoned that’s probably a good time to have an Agile project.

Joe:   So you’re saying that Waterfall would provide more structure of things for the inexperienced team, can I take that out of that or –?

Jon Q:   Yes, that’s one of the things you could take out of that and then the other would be the fact that it’s so structured gives you in theory a traceability and so at the end of the day, if the government came to call on you because your product may have harmed somebody, you have some track record or some traceability that you may not quite have that level of detail if you’re doing Agile. By definition, you forego detailed documentation.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

How Agile is Your Resource and Capacity Planning 0

I asked Jerry Manas, author of The Resource Management and Capacity Planning Handbook: A Guide to Maximizing the Value of Your Limited People Resources, that question in a recent podcast. The podcast and entire transcription can be found at Resource & Capacity Planning.

An excerpt from the podcast:

Joe:   Resource capacity and planning seems kind of very disciplined and very structured; is it?

Jerry: Well it’s structured in a way. It’s disciplined in that if you look at it contextually, with any organization, you have work coming in and there’s some kind of a brief step or to assess the work that’s coming in, if it’s bigger than a red box, where it should go, something like that, some kind of scoring or scoping or something with the work coming in. But then instead of just sending it into project execution and saying, okay let’s go – which a lot of companies do, they say okay let’s go and then resources aren’t available. Usually, you find that out when a project gets delayed or things like that.

It’s structured in the sense of as this work comes in, ideally it should hop over into some sort of investment planning or portfolio planning mode where the work can come in and you can assess it in the context of all the work in the portfolio. When you assess that, to whatever even if it’s a thinking step, whatever method you use, the idea is to bring it into the portfolio, assess where can this fit in, how does it fit in in terms of importance, what’s the available capacity to do this work and this is the part everybody leaves out, when can I do the work based on my capacity or do I need to start looking at alternative sourcing strategies and start using contractors. Contractors don’t always work for everything but if you have a strategy for it, some kind of strategy to say here are the cases where we’re going to consider bringing in contractors where it makes sense and then have those as an option, otherwise the work has to slip or really you just have limited options, either you reduce the scope and you slip the work or you bring in help. So even at that high level helps an organization.

When you plan when you can do the work, then you come over, and that’s when you can get into execution and then assigning your resources and things like that. But that missing piece, that whole capacity planning piece is what a lot of organizations skip and they don’t have the process to do that.

Joe:   I think one of the buzz words for a long time now is agile and in a lot of company, you asked anybody in any company, “Oh, we’re agile…” Does this conflict with an agile mentality or does it help it?

Jerry: Actually it helps it. In fact, I speak quite heavily about agile. The thing is with agile; it is a bit of a different animal; it really turns everything on its head. So if you look at a wonderful project, really it starts out with a plan and then you’re estimating the cost and the schedules. You’re saying, okay here’s my requirement, here’s my scope and then I’m saying, okay what’s this going to cost me to do and when can we get done? Agile literally turns that upside down. It says, okay here are the features that I like but what I’m going to do is I’m going to fix the cost and the schedule so I’m going to have a…here’s my release period or my sprints during a certain time period and now I’m going to estimate, these are the features that I think I can deliver within that schedule. So really, it’s a completely different animal that literally turns a waterfall model on its head.

But from a resource planning perspective, people say, okay well since we’re agile well does that mean we can’t plan resources? Well, with a lot of agile organizations, what I suggest is at least reserving your resources at a high level. Even if it’s at a sprint level, saying okay we’re going to reserve our resources, so you can get some kind of sense of demand because those projects consume resources too and if you’re not tracking that work at all, if those resources are isolated to a specific project, it’s not as much of an issue but if they’re shared with the rest of the organization or they’re doing other things, then you really need to at least keep track at a high level of what the resources are doing. I don’t think you need to get into detailed resource allocations like test level things because that would be a fruitless effort on an agile project but at least at a high level to be able to get a sense of demand and that way you can mix that demand in with waterfall projects or whatever other kind of projects are going on in the company.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Keys to Building a Lean Agile Software Enterprise 0

Dean Leffingwell is a consultant, entrepreneur, software executive and technical author who provides product strategy, business advisory services and enterprise-level agility coaching to large software enterprises.

Related Podcast and Transcription: Leffingwell on the Lean Agile Train

An excerpt from the podcast:

Joe:  What are the keys to building a Lean-Agile software enterprise?

Dean:  Working towards my one annual presentation, I do one trade show a year. I go to the Agile conference every year. It used to be Agile XP, and that has just grown tremendously and it’s a high-value conference. So I’ve been reframing the way I describe the way I see large enterprises being successful around five basic keys. Now I’ll describe those keys here. It might be a good way to approach the things we’re talking about. Key number one is, not everything is a user story. A user story is a really great invention. It came from XP, the user voice forum, which is, as a user; I can perform this activity so I can get business value. This is just a fantastic breakthrough in our thinking. But user stories are small because they fit inside iterations, and there are lots of them. So at the enterprise level they don’t scale very well and that’s why you see in my book “Agile Software Requirements” a three?tier, three?approach of user stories, features and epics and even a fourth year if you will which is the investment themes that drive all that.

So my first bullet thought is got to be smarter than just taking everything to a user story. The second key is at enterprise scale the way we’ve rolled out Agile historically which is a team entered a time or a Scrum mastered a time is simply too slow. So, I like to think in terms of Agile programs and not just Agile teams.

Agile programs are oriented around this construct that I’ve roughly described as the Agile release train, which is a synchronous set… Or a team with a synchronous set of iterations all timed together, working together, doing their planning, their commitment, or execution of their feedback together as one fractal above an Agile team, which has exactly the same pattern.

Thirdly, architecture emerges in Agile. It’s part of the manifesto, but I got to tell you at enterprise-class scale it can emerge in some really bad ways. And if you’re sticking together an entire portfolio or you’re doing enterprise-class business applications you can’t expect any one team or any half?a?dozen teams to have a real view of how that all needs to work together or what types of governance needs to be applied to those systems.

So, as I wrote in “Scaling Software Agility,” I’m a big fan of architecture and system architecture in the enterprise. And I call that intentional architecture, which may be flies in the face a little bit of some of our thinking. There’s some of the agilest thinking about architecture, but it can’t be strictly emergent in my view. So enterprise systems record potential architecture and I have a model for that. That was brought to me by others that I had the great privilege of working with a couple of enterprises that were quite Agile and also needed to re-architect their systems. I call that re-architecting the flow. So that’s item number three.

And fourthly if the teams are Agile and the programs are Agile, but the enterprise isn’t, if the portfolio is still being treated with fixed budgets where people must be assigned to tasks. And in month nine, in order to justify keeping them on your program or the portfolio function is driven by those who understand requirements independent of implementation and communicate that and make commitments on behalf of the teams and programs, then you’re not going to be very Agile either. And there is a set of legacy minds that are there that I think we have to cope with. So that’s item number four.

Lastly, and this is where I’ve been spending most of my time lately, and so many things are obvious in hindsight. I think we’re all brilliant in retrospect. It’s just the going forward part where we question our sanity. Lastly, your enterprise is going to be no leaner than the executives thinking and no matter what you try to do at the team or program level, until your executives are totally on board.

Not with Agile so much because Agile for them is good, sounds great, but they don’t do Scrum. They either think their teams are already empowered or maybe that’s just not a big concern of theirs, depending upon their cultural bias and mindset and history. So, we don’t have a lot of tools for them in Agile. You can’t take them the manifesto. It’s useful, and they’re interested in that but it doesn’t drive their lives.

It’s tough to communicate with high-level executives about Agile practices in a way that’s meaningful for them because they don’t do any of it. But Lean, they can think about and understanding the value stream and understand how certain, let’s just say, governance items really caused delays in the value stream and understanding that the total tack time, the touch time, we put on a system is a small percentage of the total delivery time; getting them thinking about delays in the value stream and what causes those delays and what they can do about it, is just a better approach.

I’d like to think in terms of two sub-aspects. One is Lean education and I have one go-to source now, which is Reinertsen’s new book that I like to use with executives and have them read it and sit down and discuss some of those key principles. Then lastly, you’ve got to show them how their enterprise is going to look like after the transformation, and I call that the Agile Enterprise Big Picture or the scaled Agile Delivery Model. If they don’t know how it’s going to look later they’re not going to be very comfortable with a totally self-organizing complex dynamic system that’s just all going to work out.

Even though that’s largely the case, I think the pattern of how teams and programs get organized and how values flows; how they’re involved as fiduciaries of the enterprise level; how the governance model works; how they drive the portfolio, is critical to them. Because if they can see and after they know the current picture, they know how it works now and they know there’s some challenges but they wouldn’t be reconsidering it ?? but if they can and after it just makes their life a heck of a lot easier. I call that Lean Education in the Big Picture.

So those five keys, not everything’s user story for sure, think in terms of Agile programs not just Agile teams. Admit that our large scale systems require intentional architecture. Think about some of the legacy mindsets we’ve had in portfolio management and how to address those. Then also understand that we’re going to be no leaner than the executive’s thinking. Those are the keys that I currently keep in mind whenever I approach a barbarian at the gate of the not as Agile an enterprise it wants to be.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info