Browsing articles in "Project Management"

Karen’s Rules for Being Lazy

Jun 1, 2015   //   by Karen Lopez   //   Blog, Data Modeling, DLBlog, Project Management  //  No Comments

 

image

My Dataversity Heart of Data Modeling webinar this month was titled The Best Data Modeler is a Lazy Data Modeler.

In this presentation I discuss tips for automating more of the mindless tasks in data modeling (printing, publishing, complex by rote naming of objects and more).  My rules for when to automate a task:

  • Don’t spend time doing things that a computer is faster and better at
  • Automation is your friend
  • Don’t try to automate everything at once
  • Don’t try to rebuild an entire data modeling tool in a script
  • Focus modeling time on mindful things, not mindless ones
  • If you’ve automated it, you must ask vendors to make it a feature in their tool

Check out the recording when it goes live this week.  And if you have examples of automation that we didn’t cover, let me know.  I’d love to talk about them (and use them in my own data modeling activities).

This Thursday, Big Challenges in Data Modeling: The Need for Speed #BCDModeling

May 20, 2014   //   by Karen Lopez   //   Blog, Data, Data Modeling, Events, Project Management, Speaking  //  1 Comment

 

clip_image001

22 May 2014, 2PM EDT
Register: http://www.dataversity.net/may-22-webinar-big-challenges-data-modeling/ 

It’s May, which sets this former Hoosier thinking of racetracks and Indy cars. I’m also a runner and that means I’m always thinking about pace and timings…and feeling guilty about not training hard enough.

This got me musing about how data modelers can speed up the data modeling process — not just during a development projects, but at all points in our work day. So let’s have a discussion about

In this month’s webinar, we’ll talk about:

  • The Need for Speed
  • Sprints, marathons and training
  • Race cars, horses, carts, and feet
  • Qualifiers and Races
  • Pace cars
  • Backseat drivers
  • Rules, tickets and enforcement
  • Fads, gadgets and automation
  • Red, yellow, green and checkered flags
  • How do you know when to stop racing?

 

Joining me in the discussion will be two wonderful panellists:

Donna Burbank

Donna Burbank, VP, Information Management Services at Enterprise Architects ( @donnaburbank )

Carol Lehn

Carol Lehn, MDM Database Designer at PepsiCo ( @lehnca )

And as usual, our attendees will have the opportunity to participate via chat and Q&A as our final panellist.

Register: http://www.dataversity.net/may-22-webinar-big-challenges-data-modeling/

Data Modeling…Data, Numbers and Bikinis

image

My Twitter friend Geoff Crane ( blog | @papercutpm ) made this for me today.  So I’ll just leave it here for you.

8 Tips for Presenting a Technical Recommendation

Aug 21, 2012   //   by Karen Lopez   //   Blog, Professional Development, Project Management, Speaking  //  4 Comments

 

BarbieEight

I’m asked do these sorts of “make a recommendation for a solution” presentations all the time.  I know how difficult it is.  These presentations are different than teaching moments.  They need to have a certain structure:

  • Problem statement / Challenges
  • Summary recommendation
  • Detailed recommendation (with the whys, too.)
  • Very brief recommendation of a path forward
  • Summary

So I have these tips for presenting your recommendations:

1. Make your material readable.  It sounds so non-technical and trivial to say that fonts and diagrams matter, but they do.  A recommendation that can’t be seen or read is less than useful.  Every Be The Next Microsoft Employee contestant struggled with this, some to the point that we weren’t even sure what was being presented.   Don’t let your presentation materials get in the way of presenting your ideas.  Handouts of key diagrams are always beneficial.  Using zoom features can help, too.  Buck had a great tip: put your laptop on the floor, then stand 3 metres away (okay, he said 10 feet) and see what it looks like.  If you can’t read it, neither can your audience.   If you are presenting on older projectors or without a proper screen, then stand back 12 feet.   If your slide looks like a blog post, you are doing it wrong.  Concepts go on slides, not documentation.

2. Don’t make promises you can’t keep.  All the contestants used words that could come back to haunt them later.  Words like guarantee, promise, for certain and warranty are things you can’t commit to as a vendor or presenter.  You don’t have the information you need to make these commitments, nor do you have any idea how your solution will be implemented.   Instead of making promises, case studies and well-qualified data can back up some assertions, but you will still need to use many qualifying words like may, might, and can to ensure that you aren’t making promises you can’t keep.

3. Know why are you are recommending something.  My mantra is every design decision comes down to cost, benefit and risk.  There is no one right answer for every organization, environment, team, culture or financial situation.  It’s not enough as an architect to say “this is the way that everyone does this”.  A professional architect knows that solutions need to be implemented in the context of cost, benefit and risk, including legal and organizational constraints.  Some people feel that costs and risks should not be addressed, but I have much more confidence in a recommendation when I can see that the recommender understands the trade-offs associated with everything they are proposing.  If your recommendation includes legal constraints, confirm, verify and reconfirm your recommendation.  Keeping your client out of jail is a good thing.  Context is King…and Queen.

4. Ensure that you address all the parts of the problem.  If a client asks you to solve their performance problem, all the solutions to address something else won’t make much of a difference if you don’t address the performance problem.  They may also suspect that your proposed solution can’t solve the problem in any manner.  Don’t forget the cost side, either.  Be ready with multiple levels of solutions to meet the financial constraints of the audience.

5. Ensure you don’t try to solve a problem you weren’t asked to. I’ve seen this before: a consultant has solved some brilliant problems in the past and spends all his time talking about how his solution will solve that problem…but not that was totally out of scope of the request.  Management may already have a solution in progress.  One of our contestants threw in a last second proposal to replace an ERP system, something that wasn’t asked for at all.  This would have been a real shock to everyone in the room and probably derailed the rest of the discussion.  Stick to the scope of the problem.

6. Be confident & positive.  Even if you aren’t.  I mentioned that all our presenters showed signs of nervousness. That’s to be expected.  But audiences really do want to see a confident speaker, one who speaks up and shows confidence in his or her solution.  The best way to do this is to be prepared and be confident in what you are presenting based on the resources you were given.  Don’t worry about the fact that you didn’t have enough time, that some things you wanted to demo you couldn’t get to work.  You can’t change that.  Go with what you have and do it well.  Be strong.

If you are there to provide a solution then you should be showing the meeting group that you think what you are presenting is a good thing.  Be serious, but even when you are talking about a problem or risk there’s no need to add drama to the situation.  The current environment and situation might have serious problems, but there’s no need to be negative about that.  In fact, I’ve seen consultants come in and mock the heck out of current situation and be totally oblivious that the people right in front of them built that solution and have done miracles trying to keep it going under changed demands.

7. Watch your time.  Don’t end too early nor go long.  Leave plenty of time for questions, comments and clarifications.  You can have some backup materials for anticipated questions.  I believe, though, the best use of time is for a discussion to ensure everyone understands what you have recommended and why.

8. Make your presentation about THEM.  It’s so painful to see a presenter that is clearly presenting about THE PRESENTER.  If you are saying I, my blog or my book too many times, you might be that guy.  If you are constantly pointing to yourself, you aren’t focusing on the solution.  If you are making a recommendation, it’s fine to say we recommend (if you are representing a group or organization), but you should be putting the client’s needs at the forefront.  Not yours.  One of the best ways to show that you are about them is to start your presentation with a brief understanding of the problem and the pain points of the organization.  Don’t spend too much time on it, just reflect what you’ve been told and show along the way how your recommendation addresses their pain points.

Recommendations need to have have the what, why, and how much questions addressed. They need to be clear and understandable.  I’d love to hear what recommendations you have for making technical recommendation presentations.

Please Clean Up…

Aug 13, 2012   //   by Karen Lopez   //   Blog, Data, Database, Database Design, Fun, Project Management, Snark  //  2 Comments

 

clip_image002

TSQL Tuesday: Generalist or Specialist? I Say Both #TSQL2sDay

Mar 13, 2012   //   by Karen Lopez   //   Blog, Professional Development, Project Management  //  3 Comments

TSQL2sDay150x150

My friend Argenis Fernandez (blog | @DBArgenis) is the host of this TSQL Tuesday and he’s chosen the topic of Jack of All Trades, Master of None.  This is one of my favourite discussions about the IT industry.  My interest stems from the Agile Manifesto that says:

 

The best architectures, requirements, and designs emerge from self-organizing teams.

 

This one statement, which sounds wonderful to me, is often interpreted to mean:

 

Agile teams must be made up of generalists: no specialists allowed.

 

Another interpretation is that anyone on the team must be able to do any job on the project. Most rational agile teams don’t take that extreme interpretation.  Or at least they never repeat that mistake more than a couple of times.  They learn that having people who understand things at more than a surface level will make work go faster and with less rework. 

Specialists vs. Generalists…or is is Specialists vs. Speed?

This is a very strong belief of one prominent Agilisto who is extremely vocal about this principle.   His articles and post are full scathing attacks on people who specialize.  Sure, he allows people to have a couple of specializations just for fun, but he’s clear that specialists impede the speed of a project, hold back production and generally lead to diva princesses, his name for me when I appear in debates with him.  There’s also a prominent consultancy that tells clients that no one with the words "analyst, audit, architect, administrator" will be allowed to speak to anyone on the project –teams must be just business users and team members (developers).  This consultancy is also adamant that only a developer and a clerk be able to decide on requirements and implementation issues. 

I’ve been on those projects.  We ended up with the clerk and the generalist designing and implementing a brand new way of doing accounting, with a brand new chart of accounts.  Just for one project.  They couldn’t get into QA testing because their solution was not going to pass audit, integration, security or generally accepted accounting practices reviews.  But dang, they sure did it fast.  And their new way of doing accounting led to inaccurate accounts, but that didn’t matter.  They were fast. However, they were sent back to do it all over again.  It was painful for everyone.

These are the types of things an architect, auditor, administrator and analyst would have slowed them down with by pointing out gaps in their solution.  But dang, they sure did it fast.

Over Specialization and Over Generalization

I do recognize that people can be over-specialized. You see those people all over…if you ask a question, their answer always involves the same solution or tool.  They can’t see any other way of doing something than what they know. I also know people who are fabulous at many, many things on my projects. But in my opinion, the all generalist meme really translates to:

 

Our team needs to be staffed with people who are specialists in everything.

 

Think about that for a few seconds.  What would that mean, just on your current project? Someone who knows these topics at a professional level: database, network, security, design, data, storage, development, coding, planning, estimation, capacity planning, estimation, UX, reporting, analytics, scalability, reliability, availability, quality, testing, compliance, legislation, localization, globalization, privacy, accessibility for people with disabilities, reporting, methodology, development environments.

imageNow insert the words for all the technologies used on an enterprise system.  All of them.  We need professional level people to work with all of them.  Note that professional doesn’t mean expert; it means someone who can get something done with minimal supervision. 

Then insert all the words for all the activities your entire enterprise does.  Do you have a few hundred words? A few thousand? Imagine trying to hire someone who meets all those criteria at the professional level?  Even if you could find that person, which I don’t believe you can, how much are you going to have to pay her?  Does your company have enough spare zeros hanging around to do that?  [tweet quote] What are they going to do when they need 100 more people, just like that?

Why I Hire Specialists who Make Great Generalists

So what does this mean?  I want to hire people who have a broad understanding of IT development. I want them to have a good literacy-level understand of most the things we do and use.  If they don’t have that knowledge, then they need to be able to pick it up as we go.  But I need specialists.  I don’t have time on my projects to train and mentor someone one who is going to build the database on the difference between foreign keys, alternate keys, surrogate keys, primary keys and Florida Keys.  Now if someone else on the team wants to know that, I’m happy to point to resources where they can find that out. However, my database designer needs to be able to work under minimal supervision to be able to do that.  In fact, I’d prefer that they know how implement in it in our specific technology.   They should be able to rely on external resources, but they shouldn’t have to sit at their desks with a (virtual) book open before them showing them how to do every step.  That’s a recipe for disaster. It will take longer and be more error prone.

Be Both a Specialist and a Generalist

How can you do that? By ensuring that your professional development plan (you have one, don’t you?) includes activities that strengthen both your specializations and your overall technical and non-technical skills.  That means you read about things outside your specialization.  You actually sit through a DAMA meeting or a SQLSaturday session that isn’t part of your "today job".  You expand the depth and breadth of your knowledge.  Heck you even attend a session on professional development.  Then you make sure you plan gets executed, even if it means paying for your own training or getting up early on a Saturday to attend free training at a SQLSaturday.  Maybe it means starting up a series of brown bag lunches at your company, where every group takes turn presenting 20 minutes on their favourite topic for other groups.

If you are a data architect, it means learning more about process modeling, database implementations and development tools in your shop.  If you are a DBA, it means learning more about data modeling and data compliance.  If you are a developer, it means you learn more about all of the above.  It’s up to you.  You need to take care of both your inner generalist and inner specialists.

Generalists are great…in general.  You can’t master everything, no matter what people tell you.  But your specialization won’t be much value if you can’t apply that knowledge within the context of the overall project.  You need to be both.

Pages:12»

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to www.datamodel.com by Email


Recent Comments

Categories

Archive

UA-52726617-1