Project Management

Interfacing Agile with Conventional Projects

Excerpt from a recent Podcast with Jon M. Quigley PMP CTFL 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.

From the podcast:

Joe:  Well you’ve actually used Agile in verification and interface it with conventional projects, how did you do that?

Jon Q:   Well what we did is in that instance that was a regulatory project. The talent on deck was fairly seasoned. In this case, we put the specs out, as in we knew what the specs were for the scope of the project, and then assigned — I actually had the team pick based on their talent area the pieces of the specifications that belonged where. There were a hundred different requirements and documents; it was more than 3,000 different test cases. For example, you have a guy testing on a truck, you have a lady testing on the hardware and the loop rig, those kind of things.

They would divide the specs up according to what was best for what spot and here’s the concept of self-directed work team; I did not dictate that. I was more like a scrum master. Okay, here’s what’s on deck. Here are the most important parts, the highest priority things we need to verify. Let’s divide this up and let’s start working it. And we actually had a burned-down chart of the number of test cases per each spec. It didn’t quite work out like a burned-down chart in that it was not over two or four weeks, it was more like a six-week period based on the amount of time we thought it would take to do the entire system.

They got divided up, they ran the test cases, we convened every morning and talked about the three things: what did you do yesterday, what are you going to do today, and what’s in the way? I tracked down, they tracked what they did for test cases, and we plotted that on our burned-down chart, that’s like a burned-up chart I think in that the slope was positive and not negative, instead of ours it was number of test cases conducted.

But they were all kind of elements, stolen if you would from Agile. And this part, this part of the project interfaced with a conventional, more staged gate, definitely a Waterfall kind of project. And every day or two, I would give them, the chief project manager the result of the test cases. As in, here’s our planned course, our ramped up test case per day executed, here’s what we actually did, and here’s what we found in terms of problems and that’s not necessarily an Agile thing, that’s just a test thing.

Related Podcast or Transcription: Discussing Project Methods

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

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 Amazon.com. 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)