All right, So let's talk about talk about team management. Let's go ahead and talk about some best practices that we can implement. And again, this is building on ah lot that we've already talked about. I love this.
This is a major project of utmost importance. You're not getting any money or any resource is, but it's of utmost importance. And sometimes that's the environment in which we work, you know? So we have to make the best of things planned the work,
have tools at your disposal and use them scheduling tools. You know, if you want to start very basic, sometimes people use tools like Microsoft Excel Microsoft Project. I will caution you. Microsoft Project can be challenging to work with. It is a good tool
in a small to medium environment,
but you really need to make sure that you know how to use it. Prema. They're they're a 1,000,000 you know. There's no point in even just going on and on on on naming these proud of these tools. But use tools that will help. You could create a schedule, help track your estimates, help you analyze your project.
Uh, make sure that you have the tools at your disposal that you need.
Here's an example. So, in your environment, let's say that you're migrating to exchange. Let's say you're on lotus notes, for instance, and you're gonna migrate to exchange. Welcome to the year 2015.
So what we need to do is we need to have a document defining the project. A lot of times this is done in your project charter. So in a project charter, you're gonna have some very basic information. Uh, you start with the business case. Why are we doing what we're doing? What is the purpose here
again? That's important. So that you could explain to your team
why what we're doing. We do the cost benefit analysis. We get the vision.
What are we trying to accomplish? How are we gonna know when we get there?
What are the feature scope? What work is to be produced? What sort of environment are we going to create? What are the features that this will enable
assumptions in risks? Assumptions need to be documented.
All right. I'm gonna build a sundeck for you. It will be complete by July 15th. That's assuming we have no more than 50% rain days between now and then. Right. We've got a document. Those assumptions, because what seems clear to me may not be clear to my customer.
Well, of course I can upgrade your systems because you're building has been locked for the holiday for the plant. Shut down.
You got a document, right?
How the organization is going to be effective with the roles are within the organization.
Signature page Sign, sign sign.
I need to make sure from the start, this is the project definition document. This is the first argument. Like I said, a lot of times, all this is included in the charter signed off. Let's make sure that we're thinking the same from the very get go, The more repetition
the more continued signatures I get throughout the project,
the more we can make sure we're on task. Have a planning horizon.
A ah, plan. Step by step. How are we going to do this? For those of you that have worked within Microsoft Project, for instance, you build your schedule, you have your task list. You can map that to a calendar. You can kind of see where we're going. When are our delivery bols to be produced
What are are significant
timelines. People need to know what your expectations are, and they need to be able to map that to the activities that there are responsible for
work. Breakdown structures are very useful tools. Essentially, the job of a work breakdown structure shirt is to represent the work of your project. It's a graph. It's hierarchical. Looks like an upside down organizational chart, and basically you map out the categories of work to be done within your project.
So collect requirements,
right, um, system analysis or functional design system design, implementation, whatever testing you know, those faces, maybe, and then within each category you break down into specific work packages. It's a great visual aid
to make sure that we all are on the same page. As far as the work to be done.
Network diagram helps me see the relationship in the dependency. It lets me see the flow of the project. If you've ever walked into a war room where all your project teams meeting and up on the wall, you've seen the great big chart, that sort of map together and shows the flow of the project. That's a network diagram.
document the assignment, not get acknowledgement. You know, even if it's his basic, is it signing a task in outlook and someone responds. By accepting that assignment, we need tohave a formal process. Everything needs to be documented, and we should be able to go back and find a paper trail.
Defined the procedures upfront. We've already talked about that idea. People need to know what their expectations are. They need to know best practices. They need to have a standardized directive set of directives to follow
When we're looking at change control scope management.
None of this is left to guess work.
manage the work plan and monitor the schedule and budget. So the idea is we've already developed the plan Inter planning stage, right. We have laid out what we want. The happen. We've set out the processes, the procedures, the activities, the tasks to be done. So
once we begin executing the project, we're managing that we're making sure that things are happening as they're supposed to.
Now, of course, they're not always gonna happen. Is they're supposed to. But ideally, if we have planned well,
we've also included responses to risks that come up and we're managing and making sure the work is happening as it should
monitor the schedule in budget
variants Analysis. Variant analysis is so important and my own budget or am I over or under?
AM I had a schedule on my behind schedule. My on schedule. I should be able to answer those questions because if on Week one I'm 30% behind schedule, I better do something quickly, right? Variants, Analysis. Where did I think I would be versus Where am I?
And the way variants analysis just, very simply, is done
is when you commit to your sponsor and you asked for a specific schedule in a specific baseline. I'll be done by July 15th for a budget of $300 million. Okay,
I should be able on my documentation to see the way I thought my project would go
Then. Once the project is executing, I track what's actually happening. So to take my plan versus what my actual is and look at the difference in analyze that's variants analysis.
If I don't save my plan, then I'll never know I'll never be able to do various analysis. That plan is usually referred to as a baseline
snapshot of the project. Save your baselines. Measure up against your bass lines with your actual, and that allows me to monitor the schedule in the budget.
Do this on a regular basis. Now, how regularly? I don't know. How big's your project? You know, you've got a two week project. You don't want to do it by monthly, right? So dailies too much. But you want to find a means, and that needs to be determined early on me with your sponsor.
Your sponsor wants to know if you're over budget or behind schedule. I'm pretty sure
ask your sponsor or figure out from yourself the type of project, the amount of risk, How often should variants analysis happened? It needs to be planned, and you need to keep up and meet the goals of that plan.
Our goal here is to identify tasks that are slipping war tasks that I've already slipped. But for the ones that are slipping, let's get him back on track. Various analysis is all about
Am I delivering the value that I thought I would and if not how to correct the problems. Look for warning signs. You know, um,
there have been recent security breaches in many different organizations in the last year that I've done some research and some study on and there was one that was quite egregious. And over 100 million credit card numbers were stolen from an organization.
And one of the biggest problems to me about that
waas they're auditing software worked.
You know, to me, if you've got a company and 100 million credit cards are being siphoned off your network,
don't you think there should be some system in place to go
way? Got a problem here?
So the problem that was so great to me was not that an attacker was able to compromise the network. We don't want that to happen. It does happen. The fact that they were successful toe upwards of 100 million credit cards. So what happened? Well, the audit logs after review went back and showed suspicious activity.
The problem was, the audit law was so cluttered with mundane
Over 10,000 entries, I think was said, How am I gonna pick out the 30 that are meaningful out of 10,000 that's very difficult. We need to make sure that we look for warning signs, but we need to make sure that we can actually that we can accurately monitor for those signs, right, And we have to do it on a regular basis.
So many times we go back and look at the audit logs
after a problem. So many times we go back and say We should have seen that coming. Yeah, you should have seen it coming And why didn't you? Because you didn't identify the risk early on and you didn't identify what to look for before the risk came about quality control.
When we're producing a product, start by looking at your process.
Look at your product and, UM, once you notice a decline with your product, even if it was within specs, even if with us, if it's within the specified range, when you start to see a decline in quality, you better stop and fix that process.
Because once we start to see a decline in one direction or another,
some sort of change we know there's a problem with the process, So quality assurance and quality control mandate that we evaluate. We test we audit, we inspect and we stay on top of things. Change requests, change requests and how they're handled will make
or break a project. It is that simple, and it is that
scope. Creep is one of the worst things that can happen on a project, and it's one of those things that one piece of work leads to another, leads to another, leads to another. And before you know what, you're off track, you're you're down, you know, an entirely different path
that can happen in all sorts of projects. I've seen it happen quite frequently in software development projects where you've got these brilliant developers that just want to add a little piece of functionality. And while we're doing this, let's do this and let's do that. Remember again, my goal is to meet the expectation of the customer
anything over and above the requirements,
anything over and above what the requirements that I'm providing scope, creep, it's extra work. It's not generating income. It might be something that causes another system to fail. It might keep my system from working in an environment. It's something else I have to support. So it works great today.
What about a year from now when it's not working? That's not even a feature I was paid to develop.
So we want to do is make sure that we meet the requirements of the project.
But requirements change. They may change from one of my team. We realize that something that we committed to just isn't feasible because of a change of environment or whatever reason.
The customer may come back and say, half got this one little change. The answer to scope creep is having a change management process that is robust, and it's comprehensive.
Changes should not happen on the fly. When a customer calls, Can I get this one change? It's just something little great. Let me do a little research now let you know the cost in the time associating with this,
we want ideally, to have a change control board where we write up the change. We submit the change, the change gets approved or denied. And here's the important piece. If the changes approved, we get a new baseline.
Okay, I have agreed to build a Sunday for you. It's gonna take me two weeks gonna cost $10,000. Great I'm halfway through
Sunday. Looks great. You guys do quality work. You know what? I'd like you to add some landscaping around the Sunday shouldn't take you long. Everything's already dug up. I just want you to throw a few plants in there, Okay?
Well, it's not small to me. I don't have that skill set. So I have to rely. I have to hire somebody else to do it. Or even if I do have the skill set, it will take additional time. It will also be something that the customer will have hold me accountable for providing with quality. My answer to that customer is neither yes
My answer is let me do a little research. I want to make sure that I could do this well for you. I'll give you a call back.
I do some research. I look at the impact I look at whether or not that's a risk we want to take on. And if so, I now have a new budget. I was gonna do the Sunday for 10,000. It's gonna cost 11,000. Now if I'm gonna landscape and it's gonna take me an additional four days.
If you as a customer agreed that I have a new baseline,
I am accountable to meeting my baseline
scope. Creep is not extra work. It's extra work that has not been formally approved in re baseline.
Okay, and many times a customer really believes this will only take a second. It's a small change. We have to do the research. And when a customer formally approves of the new estimates, we re baseline. And that's how you get rid of scope creep. Have a formal change control process.
The sponsor of the customer has to sign off and acknowledge the change.
We have already said not all stakeholders are created equally, many people will scream for change. Make sure you're listening to the right voices. Watch, scope, creep. Never a good reason for scope creep. Have a thorough change management process. Make sure that change management process is trained.
Make sure that it's enforced. Make sure your team members understand,
and even if there's an emergency, something's on fire, literally or figuratively. Yes, put out the fire and then write up the process. Put it through change control because many times how we respond to a situation in an emergency may not be appropriate for the long haul, so we want to make sure that the decisions that we make
are gonna be good. Decisions,
risks. We've already talked about risks. Look at your assets. Look at what you're protecting. What are they worth?
Look, a threats and vulnerabilities because that's where your risks come from. What are the weaknesses?
The potential for harm and water elements that could harm us. So whether you're risks come from inaccurate estimates, your risk comes from outsourcing to an unknown vendor, perhaps changes in the marketplace, turnover and staff. Don't forget that. That's a big risk.
You've got a developer.
You know, you're basing your estimates on his skill set. You're basing your costs on this salary that developer leaves. All of a sudden you have to hire a contractor and makes twice as much money. That's an unknown entity. What about if I'm in a unionized environment? What about my staff? Goes on strike,
you know, again, doesn't mean necessarily these air. High probability.
But you need to think about risks up front before we ever do the first piece of work. Now
I create my risk register before I ever do the first piece of work? Does that mean once I'm done, it goes in a drawer and no more risks because I have a piece of paper about risks, and we know that's not the case. You have to constantly review that risk. Register your staff meetings with your team. It's part of the reason you have these meetings.
Hey, I noticed one of our concerns. Waas such in such contract agency. How are they working for you? Are they doing well? What can we do? So we stay on top of risks. Continuously monitor for risks. Monitoring risks is a never ending project. When am I done with risks? When I'm released from the project, that's when
and then resolving issues as quickly as possible.
Earlier, we talked about variants analysis. Here's my plan that I've committed to versus what's actually happening.
If I know early on that we've got a variance, I can apply myself and try to correct it.
But if I find out a week from completion,
good grief. Look how over budget we are. Well, many counts. It's too late,
you know. And don't forget you have additional resource is go to your team, Perhaps go to your sponsor. Whatever the situation may be is thes issues arise. Go to the appropriate parties. But we don't have a head in the sand mentality. The address these issues as they come up and we do so quickly.
Ideally, we would have We may have already identified the possibility
that this risk could materialize. So we go back to our document and we look at how do we decide to respond? Or
if we've got a project management office, we can go to them. And maybe the PMO staff is going to say, you know what? The same thing happened on the last project and here's what we did. We want to foster an environment of communication sharing and again learning from our mistakes in the past.