Its quite a feat of strength to pretend you don’t have any weaknesses. I don’t pretend to be that strong.
Its quite a bit easier for me to look for faults, gaps, misses, short comings, imperfections and details that spell out why something is not right.
Its a blessing and a curse.
Looking at my deliverables in this light is second nature to me. Seek out opinions. Get critique. Make your work better. Constantly strive to push yourself.
But how often is that process of seeking critique under as much scrutiny as our work? Is it not as important? The means by which we seek out advice, and how we incorporate it is a corner stone of our work ethic.
It is much further reaching than our current project or task. It becomes part of the mechanism by which we operate. Its how we interact. Its how we present solutions and spread a sense of ownership. Its how we build teams and get stakeholders working together.
Collecting feedback, analyzing risk, determining scope are all facets of our role that we bake it into our projects. Its what makes us Business Analysts, Project Managers and good at our jobs. Its second nature.
(Image referenced from Qualtrics.com)
Until recently, what I have failed to realize about myself is where my “Assumptions & Constraints” are not being considered when I write my own “System Requirements”. Where can I improve? What about me is a risk to the business? How can we neutralize that risk?
For example, a portion of me that is very nearly atrophied since college is the ability and respect needed to accommodate deadlines. What’s the solution? If we can take a look at ourselves, at our weak areas through the lense of a requirements document, we may have immediately obtained that objective view that is necessarily to address a business problem.
Looking through the Requirement Document Lenses at Ourselves:
- Analyze ourselves and the situation to define the problem (the Root Cause); ask others for thier throughts too
- Identify what success is going to look like (our Business Requirements) when we’re done
- Outline how are we going to deliver that success story (our Functional Requirements)
- Think through all the places our impact has reaches (use cases)
- Add some limits and restrictions we’re likely to encounter when working through our problem (assumptions and constraints).
We could take this to a whole new level, and write out sample requirements – which I may yet do! – but it is enough to employ this objective tool that we use on our projects as a way to address our own business strategies.
How are we going to get where we need to be? What do we need to do to get there? What does success look like?
Going to be asking myself these questions for some time to come.
In the mean while, one of my own business concerns is the need to address my ability to meet deadlines. Its not as easy as it is to type it on your resume. It actually means something.
What is a deadline, really? Well, according to the Wiktionary:
- A date on or before which something must be completed.
- I must make this deadline or my boss will kill me!
- (archaic) A guideline marked on a plate for a printing press.
- (archaic) A line which doesn’t move.
- (archaic) A boundary around a prison
The connotation around number 4 could prove to be a bit extreme etymologically speaking, but what does this definition tell us? Probably nothing we didn’t already know. Its a date. A date by when something is due by. Not hard, right? I pay by bills by a date, I get my car’s oil changed by a date, I go to the dentist by a date. Easy peasy.
Not so much. A deadline means so much more than how its defined. As a matter of fact, weare often the ones defining the deadlines. We define the deliverables. We define the dates. Its so much more than doing something by a date, its defining what needs done by when.
Need to ask ourselves about our deadline, to help define it for our circumstance:
- What are some risk mitigation strategies for your deadlines?
- Where does your deadline get communicated?
- How to do you state your deadline?
- How soft or hard is this deadline?
- What is going to impact this deadline?
- Is this deadline clear, or clear as mud?
- What is expected at the end of the deadline?
- How do you estimate your deadline?
- When should you ask advice before giving your deadline?
- When should escalate a concern about your deadline?
Communicating and escalating risks earlier is also a key component to meeting and estimating deadlines consistently.
Here is what NOT to do:
- Provide a deadline in this format “I’ll have that to you sometime on Friday”;
- Jump on the first distracting or more fun project thrown in front of you – any chance to do something else
- Let scope creep out and destroy your project plan as that hard earned feedback rolls in;
- Wait to escalate a problem until after you’ve run out of time
Here is what you could do:
- Provide specific dates, and times
- Communicate multiple dates – be as transparent as you can be; what is the ideal/ best case scenario? What is more likely to be delivery date? What is the worst case scenario? Express your concerns immediately.
- Communicate as soon as you are aware of what will impact that will have on your plan to meet your estimated deadline
- If you are unsure, ask for time to think about it, and get back with your estimate later
- Include a confidence rating on how confident you are that deadline is likely to be met
- Don’t be easily distracted from your original plan – escalate the question to someone who can see the bigger picture, your manager or director
- “Communicating early” does not mean to wait to communicate when the deadline is slipping, it means to communicate as soon as you’ve identified something that may cause it to slip.
- When the impact of an unplanned activity has equal priority, escalate the decision immediately. Don’t think you can make that call with out being the tiniest bit subjective – when we’re that close the project, we’re often too close to make the best call for the company.
It takes time to systematically approach a problem until its second nature. Thinking of deadlines, feedback and scope creep in terms of requirements feels more systematic, more error-proof, and more organized.
Good luck, and happy self-analyzing!