Skip to main content

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/.

7 Big Tech Project Advances We Should See in Our Lifetime

Written by Brad Egeland on . Posted in Articles. 3 Comments on 7 Big Tech Project Advances We Should See in Our Lifetime

We are making major technological advances every year…every month…every day even. Some affect just a few of us while some have a lasting effect on a large portion of the population.

Looking at needs from my work and consulting perspective, there are always some “nice to haves” out there think I think should eventually be in place to make our lives, careers, and project successes better and more frequent. What’s on your list? Please read mine – these seven for now… and probably later – and share your thoughts and lists…

I call this one the Tupac.

Holographic imaging should be huge over the next 5-10 years. If it isn’t, then someone is doing something wrong. I cover this in my 3D Project Management topics, but at its basic level we should be able to conduct interactive meetings and conferences without flying across the country to meet face to face. And I’m not just talking about a head image in a box. I’m talking about project meetings where everyone is sitting at the same table and also using whiteboards or whatever in full body presence. If Tupac can perform posthumously at the huge Coachella music festival as a holograph and dance and sing then I would like to think we can figure out a way to put 10 bodies in one room from 7 different locations and save all the airline, hotel, cab and meal costs. Millions in savings every year and possibly a few lives not having your CEO on a plane when it falls from the sky.

Using AI to deliver projects.

In a recent article I wrote for Project Times entitled “AI is Saving Lives – Surely it Can Save a Project” I explained that AI was being used on 911 caller to detect of the callers were experiencing cardiac arrest. AI was detecting cardiac arrest with a 22% greater accuracy than human dispatchers so yes, I figured that sooner or later it would be cost affective and very possible to use AI on projects. How? I’m not sure. I think AI will be a huge factor in project decision making and project progress and status reporting in the future. I’d love to be part of any analysis, research, planning, and testing for this if at all possible so if anyone out there has the time, interest and money to take this on, please include me!

Automated status reports.

Doing things manually in the future will be far less common, and I believe that our project tracking tools will continue to move toward overall automated project status and progress reporting. Generating sophisticated project status reports from all-inclusive tools that do a great job of resource, budget, task, issue and change order tracking should be easy – even providing nice green, yellow and red light high level dashboard summary level reporting for the busy on the go executives you want to keep informed but who aren’t usually going to read all the details.

Advertisement
[widget id=”custom_html-68″]

Something better than waterfall and agile.

In a perfect world, in my opinion, waterfall project management and software development are still the best. If things go off without a hitch, then waterfall should be the best. But we all know project issues arise, change orders happen, requirements change, and technology is harder to implement than we are led to believe… so agile often ends up being the better course of action. I believe that in the future, another option will come about making requirements more solid and some aspects of the PM and development more automated, thus essentially superceeding either of these methods of project and solution deliver.

Walk in walk out.

This is happening with Amazon and a few other places. You have a store, you walk in, take what you want and walk out and you are charged automatically. Great idea to make the shopping experience easier and faster. I’m sure there are glitches to be worked out still, but I could also see some project management applications and tech project development applications. For example, meetings could benefit from some of this technology. The attendance, statuses, decision outcomes, and followup notes could be automated and go out to the proper stakeholders and back to the project manager through automated methods.

I’ve already worked closely with a tech conference software provider that captures badge information, qualifies leads and connects them with the right conference and product materials and the right sales person / account manager in a particular organization (like a conference vendor’s booth) just from the badge scan that happens to all of us when we go to any tech conference like CES, Interop, Black Hat, etc. This technology is cool and ahead of its time right now, but things like this will be – or at least should be – common place in the future.

No hacking.

I’ve always said that hackers are one step ahead of us. If you haven’t been hit, it’s only because you aren’t on their radar yet or you don’t have what they want. Because if they want to hack you, they could right now. At some point, I think we can not only say we are mitigating the effects of hacking or planning for the risk of hacking but that we also have fool proof ways of avoiding the hacking. We aren’t there yet – Tesla proved that for all of us. If Elon Musk – founder of Tesla and SpaceX among other things – hasn’t managed to assemble a team to void hacking, then we aren’t there yet. He professed to have developed unhackable automobile computers only to be proven wrong at the next Black Hat conference within the year. But I believe we will get there… eventually.

Automated test reporting and results.

What about automated test reporting? Is it important? Automated test reporting is becoming more and more important to project managers and certain project stakeholders. It is important for project managers to ensure this sort of reporting is available for their projects and it can help project managers manage tasks better and deliver a project on time with costs under control. There are software applications out there right now and PM service providers along side and behind that software offering this kind of service. I think in the future it will be considered an essential and readily available piece of the project management puzzle.

Summary / call for input

I realize this is just seven. I’ll probably think of four more before I go to bed at night. It’s fun to predict and report on developing trends. My thought is – if you can dream it and if it seems useful – then someone will eventually create something like it to make information better, life easier projects more successful. What are your thoughts on this list? Do you have some of your own to add? Please share and discuss.

The Best Damn Project Management Software

Written by Brad Egeland on . Posted in Articles. 5 Comments on The Best Damn Project Management Software

… Is not going to save your project. There, now that I have your attention, let’s talk software and projects.

What do you use for your project software? One tool? Many tools? Open source? Homegrown? Free? Expensive? Site license? Per-user license? Small learning curve? Large learning curve? Desktop? Cloud-based? The options are almost endless. And now hundreds of players stand where just a couple stood 20 years ago. Can one of these save your project? Probably not. Let’s discuss…

Project software these days comes from a lot of companies who are certain their offering is going to fix your project, task, resource, or financial management issues. Sometimes they have built it to solve their own scheduling and PM needs and feel they have now perfected it and it’s ready to push to the waiting PM public. I’ve worked with some of these organizations. I’ve talked to the individuals behind the software and supporting it. Usually great people. And passionate. I’ve reviewed and overviewed their software. And sometimes it just happens that their emails start to bounce because sales just weren’t happening or their product didn’t really solve anyone else’s needs like it did their own.

But who knows… it may work just perfectly for you. I believe that they all solve a need. PPM… task management… budgeting… resource planning… issue management… risk tracking… bug tracking. Does one software solve all needs? I haven’t found one yet. Can you make it through a project without any of these? Yes, I believe so, and I have. I wouldn’t recommend it on large projects – at least use a scheduling… task management/progress tool. But yes, you can get by on one project or smaller projects without any real tools if there happens to be nothing available in your organization.

What do you really need to focus on?

If you have no specific software or you’re bare bones-ing it through a project on a wing and a prayer, what do you need to manage to get through? What should you focus most or all of your attention on? Because it isn’t about what you do – it’s about doing what you need to do to succeed and even excel but not go overboard, right? So, it’s more about the best practices that are top priority. Let’s consider those…

Managing tasks.

The bottom line is this – you have to track the tasks. That is – right along with good communication – at the heart of every project no matter what shape, size, dollar amount, timeframe or industry it is in. You have to track the tasks and task progress and to do that just on paper would likely make the project essentially non-manageable. This may be the only project management task that I would say you could not just do on paper. It would make managing the team and their assigned tasks very difficult. You could use a spreadsheet, but that’s still a tool.

Advertisement
[widget id=”custom_html-68″]

Status reporting.

Reporting status on the project is key to ongoing communication and keeping all team members, all stakeholders and the customer on the same page at all times. Any word processor will do, but if you’re considering that a tool then you’re resorting to email (I’m not taking that away from anyone in 2018) and that’s ok too…and gives you easy revision, resending and tracking.

Managing the budget.

Another tough task without any tool at all – I like to go basic and use a spreadsheet, so I almost never budget within a specific project management focused tool. How about you – what do you use to track, manage, forecast and analyze project financials? I like my homegrown spreadsheet that has built-in formulas and has been re-worked over time to do exactly and track exactly what I want and what my project customers and senior management have wanted over time. I’m open to change, but not really.

Communication.

Communication is Job One – in my opinion – for the project manager and business analyst. It is at the bottom of success on every single project I’ve ever been a part of. If it goes poorly, so does the project and vice versa. But you can handle communication through phone calls, emails, and meetings if you need to. Just don’t forget to listen – that’s half of excellent communication.

Managing resources.

Again, one of those tasks that I like to do with a spreadsheet. It’s part of the project schedule in the tool, but for me only in so much as I ensure that project resources aren’t overloaded on a project at any given time. Beyond that, forecasting who I need and for how long… I build that together with my above referenced awesome project financials forecasting and analysis spreadsheet. They go hand in hand on most projects and why is that? Because your human resource is usually your most valuable and expensive piece of the project puzzle.

Issues/and risks.

Go with a list here. If you have no real issue or risk management (and I know they aren’t the same thing) tool, then a list will suffice. I often end up just using an Excel or similar spreadsheet for this anyway… nothing in a specific PM focused tool. The key, of course, is to keep all issues on the radar, know who is working on each and what the status of each is. If it’s a big enough issue, it’s going to need a task on the revised project schedule anyway.

Summary / call for input

So, the best damn project management software available isn’t going to save you or your project. It may make things easier, but until robots and artificial intelligence completely take over, it’s up to us to make the difference between success and failure on the project – not the tool or tools.

Thoughts – do you agree with me and this list? You don’t have to, but I’d love to hear feedback from you if you feel differently. Thanks!

Doing What You have to do for Project Success – it’s not Textbook

Written by Brad Egeland on . Posted in Articles. 3 Comments on Doing What You have to do for Project Success – it’s not Textbook

Calling all project teams… attention! Project success does not come easy.

You can’t wing it or phone it in. You may be able to for a short time, but success will not be yours on an ongoing basis. Project management is not easy, designing a solution is not easy, managing clients and client expectations comes with a high price and just when you think you’re done you often are not. Fool!

In order to be a good manager of team, time and money as well as the client, the business analyst needs to be a savvy communicator, a good negotiator, an independent thinker, a subject matter expert (SME) and a project manager of sorts all rolled into one. Let’s look at each of these separately…and be thinking about your own list or discussion points for my list…

Savvy communications expert.

For project managers we all know that communication is Job One, right? Well, it essentially is for business analysts as well. Maybe more communication with the home solution delivery project team than really anyone else, but the business analyst needs to be ready, willing and able to communicate well with the project customer as well as be the project manager of the moment when called upon to take over or fill in. The customer is who we are there to please, who we are there to supervise, who were are there to serve. And the business analyst is often – usually – that liaison between the tech team and the project manager. A good business analyst can also see through smoke the tech team may blow their way on project status, hours expended, etc. so they help the project manager stay apprised the to real world status of the project financials and task management issues. Again, communication is key and accurate communication is absolutely necessary on complex projects where a bit of re-work here – especially do to misunderstandings and miscommunication or ambiguity – can result in a financially failing project and that is no good.

Top notch negotiator.

We all wish it didn’t have to be that way but it does. Negotiations are part of the territory. When my wife and I traveled to South Korea in 1987 when we were adopting our now 20 year old daughter, we walked into a regular department store… similar to something like a Kohl’s… and actually negotiated a price for two umbrellas during monsoon season in July. Strange. On projects and consulting, you need to be a good negotiator. Good give and take negotiations can save key deliverables, get projects back on track in terms of timeline and due dates, can gain needed revenue on a project, can keep the project profit margin high or where it should be and – when done well – can keep customer satisfaction at a high point even when you’re getting them to pay more for new services they are asking for on the project.

Advertisement
[widget id=”custom_html-68″]

Independent idea maker.

There no doubt that the business analyst works very closely with the project manager. But he also works closely with the project team and client as well. Given that, there always going to be times when decisions must be made, ideas must be originated and formulate and project direction must be decided with or without project manager and team presence. The business analyst is sometimes going to need to be proactive and make key forward thinking decisions without the project manager and team and inform them later. It happens on nearly every project.

Expert of the technology or solution at hand.

When I say expert, I don’t mean they need to be a detailed expert – that’s what the technical team is for. But they need to be a “crossover” expert… enough technical knowledge to make key decisions and help advise the project team and client, because if that is not the case poor or insufficient decisions and directions may be taken or the customer may be make misguided decisions. The business analyst is often almost a project manager and a tech lead all at the same time. This may mean re-education, albeit very quick with the shortest learning curve imaginable if new technology is being implemented, but the business analyst often has to do what must be done. Jack of all trades? Sometimes. Which leads to my next topic…

Wannabe project manager.

While the business analyst is not the project manager, there are often times when the business analyst must become the project manager. There are times the business analyst will need to lead the weekly customer status meeting or the team meetings depending on the subject matter or the status and availability of the project manager. Some of the best project managers I know used to be business analysts and some of the best business analysts I know used to be project managers. And since my focus has been tech projects for nearly my whole career, I can say that the best business analysts have some tech background… same goes for project managers though and I can definitely say it has helped me when I’ve seen other project managers without technical backgrounds fail on large, complex project undertakings.

Summary / call for input

What are your thoughts on some of the unspoken roles the business analyst must play and the soft skill that this position really needs to possess? Did I get it right? What have I left out? Please share your own thoughts and experience – tell me when you’ve been a business analyst and had to become a database expert. I know as a project manager I’ve had to do that. Had to go from zero to sixty on a new technical skill fast while onsite with a client. It wasn’t easy but it certainly helped get data loaded while the rest of the tech staff worked through other issues as we were all trying to get back to family for Christmas. You do what you have to do.

Making the Most of Bad Requirements on a Project

Written by Brad Egeland on . Posted in Articles. 6 Comments on Making the Most of Bad Requirements on a Project

Good, complete, complex and well-documented requirements are the lifeblood of the project. With them, everything can run pretty smoothly for the duration of the project.

Design and development by the delivery team is dependent on them… so a good, workable solution is dependent on them. As is usability of the end solution by the end user population, right? So far do I seem on track as to the importance of good, detailed project requirements? What else? User acceptance testing (UAT) will have a tie in as on tech projects especially that is where testing scenarios and test cases will be built from and against. So a good user acceptance testing experience and confident outcome is dependent on having good, complete and well-documented requirements, right? Meaning final signoff on the project by the customer is at stake too…

So what happens on projects where requirements aren’t or couldn’t be documented well? What if the business processes or the project need is a bit unclear, so the project starts without well documented, complex and detailed requirements. Come on; we start long trips this way so why not projects? After all, aren’t truly full documented requirements in a very detailed form more of a luxury than a given?

How many of us have had everything spelled out as to what is needed to be accomplished before embarking on a project engagement? There comes the point when we’ve done enough planning – or really when we’ve spent enough project dollars and time planning and detailing requirements. When is that? When management or the customer sees from the budget forecast and project timeline that all of the planned efforts for requirements has been expended and that begin saying… “let’s get started already!” When this happens… you don’t have much choice… you move forward but keep these things in mind…

That re-work is possible and likely.

Whenever we are faced with vague issues during planning, then re-work during the project is possible and probable. Maybe the business processes are poorly defined, or the customer isn’t sure yet what they want (they will know it when they see it) or some similar scenario. Whatever the situation, when you’re building a solution with a roadmap that has gaps in it, you’re going to have some bumps in the road. Document whatever you can as potential risks, track all schedule deviations and manage project scope closely. Change orders are necessary for almost all projects, but we always try to keep them to a minimum so as not to risk issues with the project client. But they will be more likely on a project like this… which leads to my next topic…

Advertisement
[widget id=”custom_html-68″]

Change will happen.

Yes, on a project with less than fully documented requirements, change will happen. Clients usually aren’t too happy to hear “change order!” shouted from the rooftops, because it usually ends up meaning they have to pay more. But on a project like this, you have to make it very clear as the planning phase is closing and your client is pushing forward that the risk is high for re-work and the need for scope changes and change orders. If you’ve softened the news by declaring that early on, then the customer impact will hopefully be minimal and resistance to the change orders non-existent.

Timelines will move throughout the project.

With re-work and change orders comes timelines and dates missed or moved by the change orders. The impact can be worse than just changed dates and dollars though. It may mean you lack project resources to get the work done due to timeframe shifts or additional resources needed to cover new work that wasn’t originally planned. So onboarding, learning curves, and revisions to existing plans could all be necessary. Be prepared for this mess, because it could quickly derail the project if not monitored closely.

The budget must be monitored very closely.

I’m a proponent of watching the project budget extremely closely – to the point of forecasting and re-forecasting on a weekly basis. As I always say, “a 10% budget overrun is not too hard to fix and is usually deemed acceptable… but a 50% overrun is nearly impossible to recover from and may result in a failed project.” So, watch the budget closely – always, but especially on this type of project where expenses could mount fast – and you may be able to keep it on track. At least you’ll be able to raise the financial flag early and possibly fix the situation with a well documented and planned change order to cover the extra effort and expense as they are happening and not after the fact. It’s all part of that oh so fun project management responsibility called scope management. And never is it more apparent and needed than on the project that starts with poorly defined project requirements. So, good luck! You’re going to need it.

Summary / call for input

Starting the real work on any project knowing the requirements are more like Swiss cheese than you are comfortable with is a source of major concern for the project manager and team. It will take skilled leadership and customer oversight to keep the project on track and somewhat on time and on budget. This is not for the faint of heart nor is it a great situation for a less experienced project manager. If you can avoid one of these risky situations, do so… run. But since you likely can’t, and you’ll probably feel the adrenaline flowing for the challenge of it all, we push forward and seek project success where it may be very difficult to find. Plus, we may have been assigned to it for a reason and have no option but to make the best of it.

Thoughts? Have you been involved in many projects with vague or poorly documented requirements? Why were the requirements so bad or hard to collect? Was it a new technology or customer not really knowing what they really wanted? Please share your thoughts and experiences.

3 options for dealing with the frequent Facebook-er on the project team

Written by Brad Egeland on . Posted in Articles. 4 Comments on 3 options for dealing with the frequent Facebook-er on the project team

In 2018, Facebook is part of nearly everyone’s life who has easy access to the interweb.

In fact, we’re all surprised when we can’t find an old high school friend or college buddy on Facebook – usually assume that they must have experienced an untimely death as we can think of no other explanation. So the idea that employees would be accessing Facebook while at work is pretty much expected. I’m going to direct this one to Business Analysts because they likely have even more day to day face to face or hands-on work and communication with the rest of the project team than even the project manager does. While a tech lead may try to snow the project manager over with a 67% complete progress report on a key development task and he might buy it, the business analyst is even more likely to know that it’s more like 35%, and the tech lead is just trying to show the optimistic progress that the project schedule is requiring at this stage. And perhaps the business analyst is more keenly aware that the root cause is not encountering issues or gold plating… maybe it’s distractions due to other influences aside from work – including social media.

So, what about the employee or project team member who is using social media excessively and it’s not for work purposes? What can we do about that? These are adults – for the most part, seasoned professionals and you’re expecting big things and steady production from them. Usually, the two don’t combine and support each other. It’s hard to get approximately 8 hours a day of efficient and productive project work from someone who is carrying on a loaded social media presence during what should be work time. What do you do? Here are my main three options or actions that I would suggest…

Fire them.

In a right to hire state like Nevada where I am located, you really don’t need cause to let someone go… so you can just fire them. The upside – if you know they aren’t productive because of an addiction to checking and updating their Facebook page constantly or maybe it’s Twitter, or Instagram or some other social media outlet then you can let them go swiftly. The downside – the customer knows this project team member and any change in a key position part way through a project engagement is going to cause customer concerns… maybe a loss of confidence in the overall ability of the delivery team. But if the customer has already noticed or noted a lack of production from this individual then removing them will likely be a good thing regarding customer relations. No explaining necessary.

The likelihood that you are going to just fire them without review, investigation, or any discussion with the team member is small, though and we all know it. Just be careful because anything you say can and will be used in a court of law in this litigious era. No real rash moves are advised. Document what you can well before ever even going to the problematic team member.

Advertisement
[widget id=”custom_html-68″]

Discuss and put them on a performance improvement plan.

The next option – and probably the best and most popular option – is to discuss the concern with the project team member and put them on a performance improvement plan. Give them two weeks or 30 days to improve their performance and progress on tasks before taking any further action. It needs to be as quantitative as possible so as to not leave too much future action to question or discretion. That may be difficult in this case, so look at the project and this individual’s assigned tasks and do the best job you can coming up with something at least somewhat measurable. And if the project customer has complained about this individual, then feel free to include them in the discussion and documentation. After all, that project customer confidence and satisfaction can be used to help document reasons for terminating the project team member.

Remove the project team member from the project.

A final option is to remove the team member from the project. Since this can be done immediately without any explanation really necessary in some cases, it may be the overall best first step in the process. If the resource were extremely critical to the day to day operations of the project, then it will be more difficult, but you can explain to the project customer that this particular team member wasn’t as good of a fit as hoped and was needed on a different project or for other tasks at the moment. On boarding a new resource is time-consuming and costly, yes, but if this particular project team member hasn’t been very productive due to their lack of work focus and progress, then it probably won’t be that noticeable as they are already taking the project timeline and budget off track with their poor work performance and work ethic.

Summary/call for input

No one likes situations where they must fire someone or take performance related concerns to the next level. We all usually just wish we could close our eyes and then open them and everything would be ok. But life and projects aren’t that way. Thankfully, I’ve not had to take much action this way on projects I’ve managed – my project teams have been top notch performers for the most part. Mistakes have been made a couple of instances of over-anxious rogue development activity had to be curbed before it was too harmful to the project, but I’ve not had to deal with the distracted or slacker worker.

Readers – what about you? Have you had to take any serious action toward a project team member due to distractions or lack of work focus? Has social media gotten in the way of real project productivity? Has the customer had to come to you with these types of concerns? If so, what action or actions did you take? Please share and discuss.