0:12
>> Hello and thank you for
joining us for a final segment of the project management panelist discussion.
My name is Stephane Muller and
I'm the Director of Business Programs at UC Irvine Extension.
Discussion today will feature managing project risk and changes.
Lets meet our expert panelists.
Please meet Marty Wartenberg.
He has spent over forty years managing companies and
projects in the areas of aerospace, software, commercial product development,
oil field instrumentation and farmer research and development.
Next, we have Neil Sahota.
He's an IBM master inventor,
an Ecosystem Engagement Manager in the IBM Watson group.
Finally, we have Karen Nguyen.
She currently manages Kia Motors Americas Enterprise B2B
portal consisting of 70 dealers facing system.
Thank you everyone for your participation today.
Let's begin.
My first question is have any of you lead a project with no
formal change control process?
Please explain your experience.
>> In a, in a lot of small to medium size companies, they don't have a formal
change control board or the concept of CCB or management change board.
And what I've tried to do is implement for the project,
a project change management procedure.
You have to be able to manage change.
I've introduced change control pages where when my customer says,
I'd like you to make a change, I hand them a chance to write it up and
they'll remind me that you work for me.
So, I said, okay, I'll write it up.
And I want to get an agreement and would you like to sign it?
And nope, well, let me remind you again you work for me.
Well, okay, I'll sign it and I'll put a note that you and I discussed this change.
It's called CYA, you've got to cover yourself and
you've got to make sure that you make and you need to make the change difficult.
If you make changes too easy and you allow changes to occur on a regular basis,
then you're going to get changes on a regular basis.
So you have to sort of force your client, even though you don't have formal CCB and
formal change management to at least think about that fact that, yeah,
we have to look at the, we have to evaluate the impact of the change.
Then we'll come back and tell you and if you choose to approve it,
we'll put that in writing and we'll put it into the baseline.
>> And I find that even small or big, I think within your own team,
within your own division, you may not have change order actually change control.
And what I do is the number one thing I look for
when I come into a project is, is there a standard operating procedure?
Is there a technical style guide?
Is there some kind of workflow?
If they don't have it, that is the very first thing I do.
I do that and then I translate it to a combine board, right?
A combine board is something that it tells you by milestone and then deliverables.
So the reason I do that is not necessarily basically,
covering for myself, it's really to have a consensus where
everybody follows that procedure and you can guide that procedure.
Something where everyone knows, okay, this is the process that you're supposed to do.
Whether you're making changes, whether you're adding to the requirements.
That is what I do to help with the scope.
>> Thank you.
>> Look, I mean, today, there's always a formal change management process and
that's, just how we do business.
We won't, if there's, we go into a situation like a client doesn't have one,
we'll actually install one.
But if I look back to the start of my career back in the cowboy days of project
management.
Yeah, we there's, was often no change processes, no formalize or even informal.
But I quickly learned that at the very least,
you've got to document what's been going on.
Put it in an email and then shoot everyone a copy of it.
And I understand that, you know, there's,
there's small projects, there's small organizations.
Speed to market might be a critical thing.
You don't want to waste time on a lot of, you know,
bureaucratic processes that might slow you down.
But even in those cases, you gotta figure out what those small things are,
because you just cannot escape doing a project without some sort of change
manager process in place.
>> Thank you very much.
My next question is can any of you speak to rescuing a troubled project?
Please tell us about your experience.
>> The companies I worked for, we call, we call that thing parachuted into a,
a hot fire zone.
[LAUGH] You know, basically you're thrown into a project,
because the project manager was fired and the project's a disaster and
you're told you gotta recover it.
My experience always and what I will always do is stop the project for
a couple of days depending on the complexity and size of the project and
say, we're going to evaluate exactly where we are.
We're going to go back.
You think we're 70% done and we've completed 22 of the deliverables.
What have we actually done?
So the first thing I'll do is actually do a assessment to determine
how bad off are we and then I'll take it to the next step of saying, okay.
Here's what we have in terms of time and money how much scope can we take out and
still and be able to deliver and it being useful.
And again, you get a, a lot of push back from your sponsors.
because they still want everything and you can't have any more money,
you can't have any more time.
Well, life isn't about like that.
If there's a realism, you can't pull a miracle out.
So again showing what the realism is of the situation that, yeah,
we've spent 70% of the money, but did 15% of the work.
That means either make more money or we start pulling scope.
>> And restoring a project is more common than people think,
because project management is very volatile and
it's always changing at every phase.
And so, I had one where I was just hired into a division and
the company was going from flash-based technology to HTML5.
And for those of you who are doing course development or training,
what that means is that you're converting something to a desktop to a tablet,
so that, because our world today is, and you can go anywhere.
You can go to a paint shop and then they have a tablet, what you can do,
even Home Depot.
Right? You can do everything on a tablet.
So that's what we're trying to do in our retailer world is to convert that
to tablet.
So they can take their tests, get their knowledge,
get their credit all right there.
So what we did, what I did to rescue that project is it was one
of those most riskiest and intensive projects I've ever been in,
just because, especially in automotive.
You can't have a product out in market, a car out in market and technician and
sales consultants, don't even know the product.
Right? Like, so can you imagine the risks?
So here it is.
We have all these courses out there that is not ready to go into development.
So what I did was I pulled all of the vendors together.
I believe there's 15 of them and they pull all the technical and
they're all over the world and all over the US.
And then we would just have a daily scrim, every day quickly.
Just describe where we're at, and then an afternoon, what I call tactical meetings
issue and resolution, what's the issue, what's the resolution?
And I will break that into pieces, and I will level, like, high priority, and
we will go through that one by one, one by one, until it gets solved.
And then eventually, that we got the course out.
>> Excellent.
>> Well, I think we all have a disaster story in our back pocket.
We actually had a project working with a client where lot of,
lot of mistakes were made up front.
It was not scoped properly, improper standard requirements,
client didn't fully understand what they wanted or needed.
Unfortunately, there also been commitments made to their shareholders very publicly
about when, about dates and things like that.
And the, the project went red really quickly.
It was literally hemorrhaging millions of dollars a month.
And I got, after six months, I got called in to lead a tiger team, come in and
do the, you know, get back to green.
Planned with the client.
And again, doing a lot of things that like, Karen and Marty are talking about.
14:07
Karen, can you talk about a time when you experienced
scope creep on a project, and how you get things back on track?
>> I think all of us can experience scope creep in every project.
As a good project manager, what you need to do is control and
minimize those scope creep is the inevitable.
And I think Neal mentioned about trade offs, right?
Sometimes if you have a scope creep, you have to really
determine if you could do those trade off, and if it is still within constant time,
because those are probably better value, right?
I mean, in when you originally set forth in the requirements,
those value come into play that you probably missed in the beginning.
So how I handle scope creep, a perfect example is, we,
when we launched that enterprise, it was for desktop and tablet.
And we did not have sufficient budget to call out for mobile.
And the enterprise was so fantastic ly built from a UI front and from a UX,
which is the user experience, that they wanted to translate that to mobile.
Can you imagine telling the executives, well, we cannot have that?
So, Marty says, communication is key.
And how I handle that is, the worst thing you want,
because you're already in a volatile situation, and the worst thing you want
is to have them rally and said, we want this, we want this.
So what I do is, I call the, I break the stakeholders separately.
So I break, I break it with the exec, the executive team, the vendor,
the business unit.
So, and then I communicate those separately from different messages.
Whether it's in writing or whether in verbal, you try to explain that.
And then.
Because it's good value, we also capture it for later release.
And that is actually a good opportunity for you to come up with
a statement to get funding for next year to enhance that mobile.
17:40
Thanks a lot. Karen?
>> And like I mentioned before like Marty says,
not a lot of companies have lesson learned, and a lot- not a lot of
project managers have lesson learned, because that's icing on the cake, and
that requires a lot of writing and a lot of work.
I would love to have a more sophisticated company that focuses like, Neil,
I'm sure you have slew a of that.
We don't have that.
And like I mentioned before, as a good project manager,
it is your due diligence to try to do that.
Even though that's not the culture, that's not the company, but because you
are certified as a project manager you know that that's something good to have.
So I use lesson learned in two folds.
One, is to help other project managers and
your colleagues, to do projects better in the future.
I'm open to sharing good knowledge and good databases.
And two, is to, it's like a case study, it's to really advertise to others, this
is what it really take, this is what's behind the scene to get this end goal.
And so what I do is,
I wrote I had the team write probably a 15 page lesson learned.
And it is, again, back to stakeholders
because you don't want this to just be your side of the story.
So I asked my senior project managers to go to each user community,
the technical group, and ask them for lesson learned.
The project manager and ask them, the executive, the sponsor,
so it's a collective group of, like I said, case study.
And I find that to be very helpful and also for the organization.
As a matter of fact, I think Microsoft wants to do a case study on this
particular project and they have asked us,
actually just yesterday, if they could do that and so.
>> Thank you.
Ian?