Project Management

Software and Product Development Leads into HR?

The founder of OdBox, Matt Barcomb, partners with organizations to help leadership teams develop and deploy strategy, optimize product management and development, and evolve traditional HR functions into modern talent development practices. Matt can be found on LinkedIn or on Twitter.

Related podcast and transcription: Matt Barcomb’s Journey into Lean Software

An excerpt from the podcast:

Joe:   One of the things that I associate you with, of course, is software and product development, but it seems that umbrella has started to incorporate more parts in the company, and it’s affecting and becoming an integral part of other parts of the company. How is that affecting your work because you talk about a lot more type of organizational work, a lot more type of work with HR – is software the push into it or is it just your growth in trying to make people work together?

Matt: That’s a good question. I would probably say it’s a nice little cocktail of both. One of the reasons I got into human resources, talent development is again through client work. I would go into a place, and they were having problems hiring people that could fit for the skills and we started talking to them and then they’re kind of following a very traditional or recruiting through Monster or whatever, and they ask for help, like how do you find talent, and so we can talk about that. We wound up kind of rejiggering how they do recruiting, we kind of talked a little bit about how should they do promoting, what are their current performance plans and structure, what do those things look like, do they make sense. It’s just sort of pluck a little thing here, and you try a lot of things; a lot of companies are willing to try some things. Not every company has been willing to try all my crazy ideas, but some of them are just things that make sense. I mean I can’t remember ever being at a company ever who thought that how they did ratings, and rankings, and performance, and tying it to compensation was a wonderful, fair and equitable system that everybody enjoyed. So given that that’s never happened, one of my first principles is like well what happens if we get rid of it? Instead of trying to figure out a way to make it better or improve it or add something to the system, what if we try to simplify it first? Not that that will solve the problem, it will very likely cost other problems. But let’s take the thing away first, so when we do try to inject something, we’re injecting something into a simpler ecosystem.

Like HR is one area where we try to grow it more towards talent development, where to find people, how to promote people, how to make that a collaborative thing and I’m kind of a proponent of setting up structures such that transparent salaries could be possible. I want to be clear that I don’t necessarily advocate for going all the way towards actually making salaries transparent; it just really depends on the context. Working with sales organizations was sort of the same way. I started working more with product management as part of product development, this idea that you’ve got a group or an organization that’s sort of incented or they’re going like this to help create a product or sweeter products that has a strategic fit for a market and that they’re sort of always butting heads with this other department in the organization who’s incented to hit quarterly revenue targets at almost whatever sales price, that incented to drive some crazy behavior. I’ve seen product development departments get thrown under the bus because they couldn’t make the features fast enough, and they could have made their numbers if product had just delivered faster. I’ve seen sales departments reel because the BP of product are really hard-lined pricing strategy, and that was not allowing them to make their numbers. So trying to encourage them instead of trying to just throw sales under the bus and say, “Oh sales guys are coin-operated, evil, moron people. They should just go all be car salesman…” Let’s figure out what we’re really trying to achieve through sales.

I mean that’s a pretty obvious problem, we need the company to make money. So how we change sales and how do we change software and how do we change the product to all work together? I mean again this just taking a page out of the systems thinking kind of playbook of how are we not aligned? We have these different functions, we need a strategic fit to a market, we need to make sales, we need a revenue, we need to develop product – how do we get these three things to swim together instead of feeling like they’re often tearing the company apart?

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Taking Ownership of the IT Project

Founder of Rottie Consulting LLC, Gabriela (Gabi) Vandermark, discussies Lean Product Development with an emphasis on Product Owners.  Rottie provides consulting services to a variety of industries specializing in IT Project Management & Delivery, Technology Leadership, Organizational Change Management, Leadership Coaching, and International (South American) Relations.

This is the slide deck of the presentation we reference several times in the podcast.

 

Download MP3

Business901 iTunes Store

Mobile Version

Android APP

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Reusable Knowledge – The Focus of Lean Product Development

Rottie Consulting LLC was founded in April 2013 with the intent to provide consulting services to a variety of industries specializing in IT Project Management & Delivery, Technology Leadership, Organizational Change Management, Leadership Coaching, and International (South American) Relations. My podcast guest tomorrow is the founder of Rottie, Gabriela (Gabi) Vandermark.

An excerpt from the podcast:

Joe:   I had the pleasure of previewing your slides before your presentation and you discuss something that popped out of me that was different. When you talk about waste in Lean Product Development, you mention Reusable Knowledge. Is that a major waste? Reusable, what does that really mean?

Gabi:    Reusable Knowledge is actually the focus that you should have in Product Development. Lean Manufacturing, the focus is on removing waste, but in Lean Manufacturing, you already have a product developed, and a product identified. You’re really just finding a way to produce that and deliver that to your customer in the fastest, cheapest, quickest and most quality manner. For Lean Product Development, you’re discovering. You go from an idea all the way to market launch and to do that, you need to reuse knowledge because it’s a set of experiments. It’s that iterative process where you need to learn as you go so that you can ultimately come up with a product that is ideal for the market. In Lean Product Development, the focus is really on Reusable Knowledge. How do you share the knowledge that you gain through your iterations of that product with your entire team so that everybody can benefit from that, and even more important is how can you share that knowledge that it can be validated and complimented by other people’s ideas.

Joe:   So reusable isn’t something that is stale; the existing knowledge over in a file cabinet that you’re reusing. It’s something that you’re creating.

Gabi:    Correct and the key here is collaboration. One of the important things in Lean Product Development and Agile, in general, is how do you collaborate with your team? If you’re all collocated, it becomes not easy but it becomes a little bit more natural. You can implement visual management systems where you expose your information on boards and stickies and make it very visible to the people that are there. In my case, when I work with international projects, it becomes a little bit more challenging because we’re not physically together, but collaboration and communication are the keys to that reusable knowledge, so it doesn’t become stale.

The way I do it typically, I find ways of translating the visual management that you would think of – whiteboards and stickies to an online version. Not to plug anything but Trello is one of the tools that I use. It’s very easy to use; anybody can jump in there and there’s a lot of flexibility to build the boards that you need. So for my projects, when I’m working with people in South America where communication and collaboration is key to making sure that that knowledge that is gained, one, is spread out to the team, and two, it doesn’t become stale as you mentioned.

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?