 So let’s say you went through the 12 Questions to Ask Yourself Before Becoming an Independent Consultant—and you still want to take the plunge. This article will give you the must-do items to complete before opening your doors.
It’s common to be excited about getting your consultancy going and landing that first gig—passion is great! But you absolutely need to get a few things in order first. I can’t stress this enough: If you skip over considering the 10 steps below, you are setting yourself up for potentially big problems later. This is a “measure twice, cut once” thing. (I think you get my point by now…) My experience is setting up a U.S. company in the state of Washington. You should use the advisors and other suggestions that are right for your consultancy’s location. Read more at ProjectManagement.com
0 Comments
 In The Secret to Managing RAID Effectively (Part 1), I introduced the RAID 101 model, which articulates the interrelationships between risks, assumptions, issues and dependencies. The model has six main components:
Read more at ProjectManagement.com.  In my four decades as a professional, I’ve worked as a consultant at Accenture, hired consultants at Microsoft, and engaged with many clients while running my own firm. I’ve seen consulting from many different vantage points—some very positive, others not so much.
Of all these, I have by far enjoyed working in my own consultancy the most. I’m in no way trying to dismiss Accenture or Microsoft; I’m still on friendly terms with them, and strongly advocate them as employers. But going off on my own worked out best for me. Hanging your own shingle is a bit like a bungee jump: it’s exciting, exhilarating and scary all at the same time. I’ve learned that branching off as an independent consultant isn’t for everyone, and that the most important first step anyone could take is to do some honest introspection on whether being an independent consultant is for him or her. To that end, I have developed 12 questions that I believe are important to ask if you want to be your own consulting boss: Read more at ProjectManagement.com.  Risks. Assumptions. Issues. Dependencies.
Four concepts that almost every project manager has dealt with in one form or another. When managed effectively, they significantly reduce execution friction and better secure scope, schedule and budget success. When not managed effectively, it’s like riding a bike with the brakes engaged—you may ultimately get to where you want to be, but it takes a lot more effort to get there. Key to managing risks, assumptions, issues and dependencies (RAID) effectively is not just understanding each concept—it’s truly internalizing how the concepts interrelate. Understanding the interrelationships better positions the PM to not just manage each individual RAID component, but also to proactively address problems and avert scope, schedule or budget impacts. To that end, my focus is to not just explain each of the RAID components, but to demonstrate the connection points between them. In my view, which I call the RAID 101 Model, the relationships look as follows: Read more at ProjectManagement.com  Our son, Trevor, has worked for our company twice—once right after he graduated from college in 2015, and again in September 2021 after working three years at a non-profit. His official title is Chief Storyteller.
Since working for us, Trevor has written and published two books, re-illustrated a third, and is actively learning the publishing business. He also has a goal of writing young adult books, and as of this writing is working on his first fiction piece. Trevor was diagnosed with autism spectrum disorder at age 6, and throughout his life has had his share of challenges. When we first hired Trevor, we were faced with how to align on goals, give him some flexibility as to how he achieved the goals, and avoid micro-managing him with frequent “What are you working on today?” requests. To address the need, we devised something we call the “dones” process, which aligns us on long-term goals and short-term deliverables that align to the long-term goals. We have successfully been using this throughout his employment tenure, and it has proven to be effective in keeping my wife Patty and I aligned with Trevor’s work. After I told a few colleagues about the process, I consistently heard how valuable this could be for neurotypical people, not just for people on the autism spectrum. So I wanted to explain precisely how we manage to dones and provide a tool you can use with your leader (or if you are a leader yourself, use with your staff). Read more on ProjectManagement.com.  When a PM muddies the water with statements like “everything is critical” to those who truly understand how a project’s critical path works, the PM causes others to question both the PM’s schedule and—more importantly—the PM’s credibility. Understanding the mechanics of critical path is a crucial hard skill that PMs need to master early in their careers.
Before we go further, I’d like to define some basics that affect a project’s critical path... Read more at ProjectManagement.com 
People who are strategic in nature are effective at the why and what. They can paint a clear, compelling vision of some future state and get others to align to the future state. This skill is super critical in generating excitement and buy-in on the “what could be.”
People who are tactical are effective at the how, who and when. They can ingest the compelling vision and translate it into an executable plan while effectively managing scope, schedule and budget. This skill is imperative if the strategist’s great idea is ever going to make it beyond slideware. There are some, though, who are competent at the why and what as well as translating it into how, who and when. They can be strategic, but can also switch hats when the situation dictates and be tactical. Those who can do this are what I like to think of as stractical (my made-up word). Read more at ProjectManagement.com.  As a new manager at Andersen Consulting (now Accenture), I was determined to show others how it was done. But I took on too many clients simultaneously and didn’t ask for help. When a colleague tried to tell me things were going south, I ignored him. My stubbornness, naivete and ignorance led to screwing up not one job, but three.
Not only did I mess things up, but I wasn’t honest with myself about what happened, why it happened, and how I contributed to it. I was accountable for three spectacular failures, and for years was in denial of my own culpability. I was also too proud to admit my failures to colleagues and management and help others learn from them. Later in my career, I came to grips with what happened and was willing to share the experience with others. But there were times along the way I could have helped others but didn’t. Bad on me. Read more at ProjectManagement.com  In the Rough-Cut Timeboxing: The Work-Back Model article, I addressed the scenario of the project manager being given an end date and having to work backward to derive when the initiative should start (or should have started). But what about the scenario where a project manager is able to provide a start date?
My experience has been more about being given an end date, but I’ve also had situations where I was able to forward-schedule work—or where I used forward and backward scheduling together to develop a rough-cut plan. In this article, I want to focus on that scenario using the rough-cut work-forward timebox model. Read more at ProjectManagement.com  Recently, my wife and I were on a social visit with a friend I’ll call Vick. We were enjoying beverages and light chatter when suddenly the topic changed to world events. It was like a light switch turned on, with Vick becoming very animated about the topic, spewing data point after data point, and aggressively quizzing me on whether I had heard about some of the points he was raising.
When I replied “no,” his response was incredulous. “You mean you haven’t heard of _____?” he asked, as if I were the only person on Earth who didn’t know what he was talking about. This went on for about an hour before we resumed talking about lighter topics. I thought about the interaction that evening, and the next day texted him a follow-up question. The onslaught resumed, and after a while I decided to disengage because I saw that no good would come of the exchange. I later thought about both the face-to-face and the text interactions, and came up with some important elements that were there—and some that were missing: Read more at ProjectManagement.com |
Topics
All
Reprints
Contact Lonnie about article reprints. Please specify article you wish to reprint. Backlist
See Lonnie's Amazon Author Page Archives
December 2023
|
RSS Feed