Author: Brad Egeland

Brad Egeland is a Business Solution Designer and IT/PM consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Creative Design, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been named the “#1 Provider of Project Management Content in the World” with over 7,000 published articles, eBooks, white papers and videos. Brad is married, a father of 11, and living in sunny Las Vegas, NV. Visit Brad's site at http://www.bradegeland.com/.

Cyber Security: Legitimate Project Concern?

Written by Brad Egeland on September 25, 2015. Posted in Articles. 3 Comments on Cyber Security: Legitimate Project Concern?

We have lots of risks on the projects we manage. Sometimes we set aside a decent amount of planning time to identify potential risks and plan for their mitigation or better yet, their avoidance. Sometimes we don’t.

We should, but we don’t always do it and even when we do we probably don’t spend as much time on risk planning as we should. I should know! I speak from 20+ years of experience leading IT projects and initiatives, and while I’ve thankfully been pretty successful and learned lessons along the way, I’m no angel.

There have been quite a few incidents of data breaches, large-scale credit card info thefts from big box change stores and even breaches in government databases over the past 12 months. These have all received great press, but that doesn’t mean they go away.

In fact, I think that it just makes it that much more likely – given the publicity – for these same hackers and other hackers to go the extra distance to find new targets and industries to hack. Sometimes it is done for ransom or to prove a point, and sometimes it is just done for the hacker’s curiosity and enjoyment.

Black Hat Security Conference Relevance

Recently, I attended Black Hat USA 2015 here in Las Vegas and made sure that one of the briefings I attended was the latest findings (aka, “hackings”) of Charlie Miller and Chris Valasek. By the time Black Hat USA 2014 started last year, they had already taken control of a 2014 Jeep Cherokee’s stereo system. They forced it to play Kanye West very loudly while overriding the dash controls remotely so that the driver was unable to change the station or volume. Impressive, but they were far from done.

Miller and Valsasek’s latest hackings had received quite a bit of press about 1-2 weeks before Black Hat, so I was greatly anticipating this show of hacking expertise. I was not disappointed. The pair presented the culmination of a year’s worth of effort to take control of a vehicle’s computer system in their briefing “Remote Exploitation of an Unaltered Passenger Vehicle”. The briefing outlined how they were able to send CAN messages to the vehicle’s computer to make the Jeep speed up, steer without driver input, override the anti-collision mechanism, and drive into a ditch with a nervous reporter inside. I look forward to seeing what they’ve accomplished by Black Hat 2016.

And just in case you didn’t hear about it, their work directly resulted in Chrysler’s recall of 1.4 million vehicles. Not bad!

Should we be concerned with data security on our projects?

So, is cyber security a legitimate concern? After watching a season of CSI: Cyber and attending Black Hat USA for the 4th year in a row, I’m convinced that it is, indeed, a legitimate concern. It is a huge concern for our data centers, a huge concern for IT shops everywhere, a huge concern for every government agency on the map. It needs to be a concern and consideration on every project that we manage. I’m not saying that we have to spend millions or even tens of thousands of dollars on it. I’m just saying it needs to be a concern and consideration. Something to which we must give some thoughtful planning and management time. If we dismiss it because it is not related to our current project, then that is great, but it should be addressed.

What do we do about it?

Assuming we consider it a big enough issue to incorporate into the planning process– which I feel we should – what do we do about it?

Here is a simple three consideration process to go through – at least at a very high level – to determine to what extent that type of security is something we should plan for and expend project dollars. The detail you give it, and the amount of time and complexity you plan into it is dependent on your organization’s policies, your customer’s needs and preferences, and the type and complexity of the project you are managing.

Consider what you are protecting. Is the data invaluable? Is it irreplaceable? Would a hack be devastating to your organization? Would it affect your customers, clients, or the customers of your clients? Consider these questions carefully. The ripple effect is unimaginable in certain situations. If you or your customer is handling health data and there is a database breach, consider how much data is now available to hackers, the general public, or criminals with ill intent. Does this need to be protected? Absolutely, and at just about any cost.

Consider the skills needed. Look at your organization. Is there anyone in the organization that can build out the level of protection your specific data will need? Cyber security experts don’t come cheap. Hacks now are different than the data issues of 20 or 30 years ago. As they stated at Black Hat USA 2015, everything can be hacked. If you say it can’t be hacked, it only makes you a quick target for someone looking to prove you wrong.

Consider the cost. Can your project, your client, or your organization afford the expertise and protective measures you are likely going to need? If you find that it is far more expensive than anyone imagined, then you have two options. The first is to pass on this opportunity because the potential for loss of any profits is real. The second option is to reach out to the project client for a change order to cover the cost of bringing in the expertise and technology that will be necessary to protect any sensitive data you will be handling for them.

Here’s the bottom line

If you’re looking out for millions of financial records, then yes, you will need to take some extreme data security measures and probably run every individual through background checks who will even have the remote chance of accessing the data you must protect. Depending on the projects I’ve led and the organizations where I’ve worked, I have held top-secret FBI security clearances off and on throughout the 30 years that I have been in the IT industry.

What are your thoughts on cyber security from a project management standpoint? Are you concerned about security? Has a sensitive database on one of your projects ever been hacked? What was the outcome? Please share your thoughts and experiences.

Have You QA’d Your Project Processes Lately?

Written by Brad Egeland on August 11, 2015. Posted in Articles. 3 Comments on Have You QA’d Your Project Processes Lately?

Best practices are best practices, right? Ummm…yeah…no. What you started out doing on projects five years ago may not be what you should be doing today for your projects and project clients. Look at how your organization has changed. Has your industry changed? Have your customers changed? Things just don’t stay the same in today’s world. They say business moves at the speed of change. What is that change? How much has changed? You have first to consider these questions before you can figure out how to respond to those changes.

Do you need to update your delivery methods and processes on projects? Probably. But there are key things you need to consider – it’s not just a situation where you brainstorm on what to do better. You must consider your organization, your project clients, the technology you use and deliver, your industry, and even your senior management’s plans. Let’s discuss the following and see how to approach this.

Consider how your organization has changed. Is your organization where it was five or ten years ago? Not likely. Is it tied to the same industry? Likely. But it has also likely expanded beyond the boundaries of its earlier mapped out mission, goals, and industry walls. The landscape of nearly every organization and nearly every industry has changed. We must figure out how our project management infrastructure needs to change to fit the needs of our organization. Does reporting to senior management need to change? Or maybe you weren’t doing that before, and now you need to. Let’s map that out as a PM team and get it right the first time. Guessing and tweaking over and over does no one any good and will just frustrate your executive management team.

Consider how your clients have changed. Do you have the same project clients you had five years ago? Are you delivering the same types of project solutions to them? If many of your clients are the same, this PM introspective is probably a good time to sit down with some of the best of the best clients and quiz them on a few things. Ask them how their businesses have changed over the last five years. Ask them how they think the industry has changed during that timeframe. You may already be learning this through lessons learned sessions, but ask them how you can be serving them better on the projects that you are leading for them. Sometimes it’s tough to hear, but you want the real picture, right? The flip side is for them just to walk away after the next project or the current project, and you don’t want that. Ask them – and then take that info back as a PM group and use it to analyze how you are delivering on your projects. Are you meeting those needs? What can you change to better suit your customers’ needs and to deliver better they way they just told you they’d like to see you deliver. Don’t fail to act on this important insight you were just handed by valued project clients. Do something about it.

Consider how your industry has changed. Has your industry changed significantly so as to force you to consider how you are delivering projects? Sometimes regulations change, reporting needs change, compliance requirements change. Sometimes you have to revisit these processes periodically just for legal reasons alone. But if you’re an industry leader – or strive to be one – then you need to periodically assess where you stand in that industry and look at your internal processes to see where they may be holding you back or keeping you from grabbing the biggest project clients in your particular industry. And change.

Consider the changing technology for the types of solutions you are implementing. Has the technology landscape changed for the types of projects you are delivering? Most likely the answer to this is yes. Technology is always changing. And if you are remaining stagnate, going with the status quo, then you are going to get passed by every close competitor in your industry. Stay current, train staff, and analyze how you can offer and utilize the latest technology on upcoming projects.

Check in with senior management. This may seem like an after thought, but you need to know where your company’s senior management is going. They may be changing a delivery focus. They may be changing a technology or product focus. They may be changing a customer landscape focus. What they are planning for the next one to five years could affect the project delivery system in your organization, and you need to know that. Ask. If you’re not the PMO director, get them to ask. Or, if you’re connected with C-levels in the organization, ask them. It’s important to be thinking about the company direction when you are working to figure out the best way to be delivering on projects now and in the short and long term future. Project success can be fleeting as we all know. Be informed of the company roadmap as best you can so as to be making the best decisions on any process changes in your project delivery processes and methodology.

Nothing stays the same. Times change. Needs change. Technology definitely changes. Customer wants and needs change. The organization that doesn’t periodically re-evaluate how and what they are delivering loses. Period. As an organization and yes, as a project management infrastructure, we need to bear witness to these changes and evaluate whether or not we need to change how and what we are delivering. Most likely we do.

One way organizations evaluate how what may need to change is to have brainstorming sessions with project managers and key project team members every year or every six months. Look at templates, policies, processes, lessons learned. Evaluate what is working, and what should change. And, together, propose those changes and begin to incorporate those changes during such brainstorming sessions.

How does your organization analyze the need to change and incorporate project process changes? What steps, if any, do you go through? Please share and discuss.

5 Things to Know Before You Start the Project

Written by Brad Egeland on July 14, 2015. Posted in Articles. 5 Comments on 5 Things to Know Before You Start the Project

Eager project managers – and new project managers – may like to jump in head first into a new project and show enthusiasm to prove to their senior management that they are go-getters. That’s nice, but it may also be stupid. These overly eager PMs may be sending the wrong message to their leadership, who are really looking to see if they show any knowledge at all about how they should go cautiously into the night on a project… not jump in with pistols blazing.

The best way to start the project properly is to go into the engagement knowing a few things first. Make sure both feet are firmly planted on the ground, and you are ready to serve the customer appropriately.

This all comes to mind mainly because – amazingly – I was handed a project where nothing was known. Seriously… nothing. We had a developer working on the project already. He was doing some preliminary work on an interface for the project working with a customer-side project manager. Other than the generic interface we were tasked to do, we knew nothing about the project. Nothing. And I was about to jump on a call with the sponsor on the customer side. I had nothing to go on – no documents, no status reports (everything had been verbal sprint meetings to this point), and no statement of work (SOW). Nothing. Ummm…ok. Actually really it was not ok.

So, here’s my list of a 5 key things I like to know going into a project:

What exactly is expected of the PM and team? It is imperative that the project manager knows what the team should be delivering. Without proper documentation such as a statement of work, previous notes, or status reports, a project manager is blind heading into any discussion they are having with the project sponsor and customer team. It’s a no win situation – no ability to plan, no ability to ask or answer questions intelligently. Before starting a project or taking over a project, even before engaging the client, the project manager needs an idea at least of what the project involves.

Is funding in place? Is there money for this effort? This tells you how serious the project customer is. Are they looking for free advice or are they really planning to engage your services? I had a potential consulting client who I suspected was just looking for me to propose something so he could refine his idea for a project. He basically wanted a free strategy proposal. I created a proposal – a good one and it was detailed – but I also required that it be a paid deliverable. He was surprised, but he paid for it. I knew it was the only money I was going to get from him because he was just fishing and I couldn’t afford to give my time away for free.

Does a legacy system exist? Are we building something new or is there a legacy system in place that currently does this work? Knowing this can help project managers figure out a few things like what not to do, or possibly give some added insight into current business processes. This knowledge may make the project more affordable for the client by being able to propose an add-on to the existing functionality to cover the needed feature rather than completely rebuild the system. There are always options – PMs just need the full picture in order to propose those options.

What data integrations will be necessary? If you are still working through the financials and pricing for the project, then whether or not loading legacy data into the system and how this data will be integrated are two critical pieces of information. It may seem trivial, but data can be very complex. Loading old data may mean data needs to be cleansed – basically cleaned up and reformatted to fit into a new solution. And as far as integrating it into a new solution – tying it into the data fields and getting the new functionality to talk to the existing data the way it needs to can be very difficult. This is key information that is needed for requirements definition and pricing.

What is the timeframe for the project? Finally, when is this project needed? You may start out putting together a plan based on what you have been given to and are about to propose a 14-month timeline to the project sponsor. It would be very helpful to know from the project sponsor that they MUST have the solution within 6 months. Knowing the timeline before you put the effort into the schedule allows you to either plan to meet that incredibly tight timeframe or plan a phased implementation. You will need to begin planning negotiation points on why your approach will work for them.

Summary

Heading into the unknown is tough. Project managers can waste a lot of time and look like fools in the process if they try to plan for and prepare a project engagement that they know little about. The key is to get as much information as possible up front. Knowing the right information is critical to planning properly, making good estimating and team building preparations, high-level requirements definition, and knowing how to prepare for and execute any project kickoff activities. Going into a project engagement or any discussion with the potential project sponsor completely blind is dangerous and can lead to a project not getting off on the right foot.

What’s your take on this? When have you had to take on a project with nothing to go on? What did you do? If you were a consultant, did you skip that project? Did you dig further? Did you head into meetings with no clue hoping to gather some helpful information? What other key info – especially on tech projects – other than what I’ve listed above, do you usually need to know before getting started or even meeting with the client?

Don’t forget to leave your comments below.

The Good Project Meeting

Written by Brad Egeland on June 3, 2015. Posted in Articles. 8 Comments on The Good Project Meeting

I had to laugh at this one. I was meeting with a potential new client this morning and he talked about the concept of the “good meeting” on projects. You know the ones – everyone comes out of the meeting saying, “good meeting!” But when asked what was accomplished no one can really pinpoint anything of any significance.

The really sad thing is this – when that happens for a two hour project meeting with an attendee list of 6-8 individuals, you suddenly realize you just blew through somewhere between $500 and $2,000 of billable time. The PM now has that much less left of the project budget to work with and nothing was accomplished that couldn’t have been handled more successfully in a 5-minute email. Do that weekly over the course of a 6-month project and that amounts to anywhere from $10,000 to $50,000 of worthless, unproductive charges against the crucial project budget for dead weight meetings. Ouch – that hurts.

How do we combat the “Good Meeting”? In my opinion, it is through the following six key activities:

Prepare in advance
Have a detailed agenda
Stick to the meeting timeframe
Stay on topic
Structure the meeting for maximum participation
Perform thorough follow-up

Let’s examine each in more detail.

Prepare in advance. Preparing in advance is just that – advanced planning ahead of the meeting. Don’t just throw together an agenda and send it out. Plan well, think about how you’re going to strategize and discuss and assign tasks to keep the meeting flowing, keep everyone awake, and allow for the best information dissemination possible. You certainly don’t have to go overboard in the meeting planning process – too much would be a waste of time and money – but a little planning can go a long way. You just don’t want to arrive, start leading the meeting, and have everyone feel like you threw it together at the last minute. You want the meeting to be productive.

Have a detailed agenda. Always have a well planned out agenda designed to keep the meeting and information flowing. The agenda is the catalyst to help ensure you have an efficient and productive meeting that will help key decisions happen, assignments get made, next steps get planned and issues get reviewed. This your chance – with all the right key players in the room – to give and get good information. Make the most of it.

A good agenda also helps the meeting stay on track. A meeting that stays on track is one that stays in alignment with the timeframe planned for the meeting, which leads us to the next concept…staying on schedule.

Stick to the schedule. The best way to always have the highest attendance possible, and to gain a reputation as a great meeting facilitator, is to stick to the meeting schedule and agenda you proposed in the advanced meeting communication. Start on time, finish on time, and don’t cancel. Start on time even if you have late arrivals, and finish on time by not allowing you or participants to stray off topic.

And if there isn’t much to cover and it’s your regular weekly meeting, don’t cancel. Better to have a short meeting where not much gets discussed if there isn’t much to discuss than to cancel an ongoing regularly scheduled meeting. If you start to cancel those regular meetings people will start to consider your meetings as “expendable” and “optional” and your attendance will dwindle. Trust me, it will happen. Plus, you never know when something may need to be said even when the project is currently in a lull. If you skip that meeting – even if it ends up only being a 10-minute meeting – a key piece of information that your tech lead has from the customer that you need to hear might otherwise fall through the cracks. And that may have been a critical piece to the project puzzle but it becomes a forgotten piece until it’s too late.

Stay on topic. I can’t stress this one enough. It’s nice that people get together and talk trash or talk about their weekends or work on other projects – but not during your meeting and not on your project time. Plus, they are thoroughly boring everyone else in the meeting who want to be productive and move on to the rest of their day. You don’t want YOUR meeting wasting their time. That’s a very bad reputation to have and a hard one to get rid of.

Structure it for attendee participation. Always structure your meeting – and the agenda leading into it – for maximum attendee participation. Not only will it keep everyone awake and alert, but you’ll accomplish a lot more than those meetings where the facilitator just drones on and on about whatever topic they are providing information on. If all you need to do is disseminate information, do that through emails – it’s faster and more efficient. One-way communication is great for email. But for those things on the project that need to be discussed and decisions made – use the meeting for those. You have everyone together in one room – all the key stakeholders – use that time to make progress on the items and issues that can’t just be handled through one-way communication.

Follow-up after the meeting. Always follow up with notes after the meeting. That way you can ensure everyone is on the same page and everyone has equal understanding of the information provided, the discussions that happened, the decisions made, and the assignments and expectations that were allocated. I like to update the latest status report – usually what I’m using to drive the project meeting and what the agenda originates from – with whatever information and decisions came out of the meeting. I send that out to everyone and give them 24 hours to get back to me with any changes or things they think I may have miscommunicated. Then, I resend the revised info out again to all attendees – and anyone who couldn’t make it – so as to ensure we are now once again on the same page.

Summary

Meetings can be a big waste of time. Or they can be extremely productive. It’s generally up to you and how you plan for and organize your meetings. The better you plan, the more organized you are, the more you stick to your schedule, the better your meeting attendance and participation will be. With all that in place, you’ll be far more likely to have a truly good meeting…not one of those “good meetings” that everyone walks out of looking sleepy and shaking their heads.

Don’t forget to leave your comments below.

Turning Bad Requirements into Good Requirements

Written by Brad Egeland on March 20, 2015. Posted in Articles. 3 Comments on Turning Bad Requirements into Good Requirements

Bad requirements or no requirements are definitely not the best way to start any technical project. But most project managers will tell you that you aren’t likely to get your best requirements from your project customer – no matter how certain they may be that they have thoroughly documented everything for you. The problem is, some project customers aren’t even certain they know the right problem or need that the project is going to be addressing for them. In those cases – and that’s often from my experiences – there is no way a project client could have good, detailed requirements waiting for you. They don’t even know the real problem yet…they’ve likely only documented a symptom.

The bottom line is this – customers are not often known for providing good requirements for the solutions they are seeking from the project teams. Ideally, customers would have met internally with their end users and subject matter experts (SMEs) to determine exactly what the problem is, what the real project is, and at least what the high-level requirements are that need to be met by the project team as they develop and implement the solution. In reality, those end users are all too often overlooked leaving us to roll out a solution to them that may or may not help them to do their jobs better. And if it doesn’t solve the need – no matter how we point our fingers, it is we who have failed the project customer, not the other way around.

In order to get to the point where the project team knows what needs to be done and exactly what is expected of them, a few steps must happen. From my experiences, I’ve narrowed it down to the following four key steps or processes we must go through as a project team. In order to get a good handle on real requirements and produce a working end solution for the critical end users, the project team must…

Get initial requirements from the customer at project initiation
Kick the project off formally and set expectations
Define detailed requirements with the customer
Track requirements with a traceability matrix

Let’s look at each of these in more detail.

Get initial requirements from the customer at project initiation

Like it or not, our starting point needs to be whatever the project customer can supply in terms of project requirements. We can’t run with these because they likely aren’t going to be complete enough to serve the need of real, complete, detailed requirements. By definition, in order to be a good requirement, it must be unitary (define one thing), complete, consistent, non-conjugated, traceable, current, unambiguous, specify importance, and be verifiable. We may get there with the help of the project client – we have to – but it’s not likely that the client will get there on their own.

There’s no way the project manager can know how ready the customer is with their true project request until he sees what preparation they’ve already put into the engagement. Plus, knowledge of the customer’s preparation status is absolutely necessary to adequately map out a project schedule and how much time the planning phase is going to require – something that is a critical input into the project kickoff session.

Kick the project off formally and set expectations

With all customer pre-project preparation information in hand, the project manager is now ready to put together a draft project schedule based on this information and any information obtained at the handoff from sales to project management. At a minimum this should include the statement of work, original estimate, assumptions, and planned resources.

Once the project manager has the draft project schedule ready, a kickoff agenda in place, and a formal presentation prepared, the kickoff meeting needs to be held with the customer and the customer project team. This is the meeting where expectations are set, the schedule is reviewed and agreed upon, deliverables and milestones are finalized, and the final project planning gets set in motion.

Define detailed requirements with the customer

Following the project kickoff meeting, the project team will work with the customer on further project planning activities. The key activity is the detailed definition of the project requirements including asking the right questions of the customer, customer team, and customer SMEs and end users to truly identify what the real needs of the project are. That’s the only way that the project team can effectively identify the detailed requirements for the customer and the only way they can confidently embark on developing a project solution that they know will meet the customer’s end user needs once the solution is deployed at the end of the engagement.

Track requirements with a traceability matrix

As I’ve stated, documenting accurate, detailed requirements is important, but that’s not the end of the requirements work. The best way to both document requirements and to know that those requirements have been built in to the final solution is to create a requirements traceability matrix. This becomes a living, breathing matrix for the rest of the engagement. It will be created in design, updated in development to show where each requirement is built in to the solution, checked in testing and user acceptance testing to be sure all functionality works, and then signed off by the customer as part of system acceptance at deployment.

Summary

Requirements are the lifeblood of the project. Bad requirements = a bad project that usually involves much rework, a blown budget and timeline, and usually ends with a dissatisfied customer and a frustrated end user base. That’s bad…obviously. These four steps or actions are not going to guarantee success or that you even have great requirements to work from. Projects fail, requirements change without realizing it, and customer systems are often complex – meaning it’s not easy to capture good requirements every time. It’s our responsibility as project managers to build adequate time into the project timeline and budget for planning and defining project requirements. This ensures better footing as we try to move beyond planning and into the real work of designing and building out the customer solution. Plus, good and detailed requirements makes user acceptance testing easier (and better) which also serves to ensure those end users are getting what they need in the long run.

By understanding the real issue or issues, documenting detailed requirements, and tracking those requirements through a traceability matrix to ensure they are built in to the design of the solution, the project team can be confident that the customer’s end users will receive a solution that they can productively use. The end result will be a successful implementation and a satisfied project customer.

Don’t forget to leave your comments below.