Bob Lambert

Jazz on the harmonica

Category: Project Management

  • Values and Behaviors of the Successful Agilist

    Of course, any discussion of Agile values starts with the Agile Manifesto. The first sentence declares that Agile development is about seeking better ways and helping others. Then, as if espousing self-evident truths, the founders present four relative value statements. Finally, they emphasize appropriate balance, saying that the relatively less valued items aren’t worthless: implying…

    continue reading

  • Tableau Rollout Across Five Dimensions

    Standing up any new analytics tool in an organization is complex, and early on, new adopters of Tableau often struggle to include all the complexities in their plan. This post proposes a mental model in the form of a story of how Tableau might have rolled out in one hypothetical installation to uncover common challenges for…

    continue reading

  • Analytics Requirements: Avoid a Y2.xK Crisis

    Even though it happens annually, teams building new visualizations often forget to think about the effects of turning over from one year to another. In today’s fast paced, Agile world, requirements for even the most critical dashboards and visualizations tend to evolve, and development often proceeds iteratively from a scratchpad sketch through successively more detailed…

    continue reading

  • Protect Your Culture: Screening for authoritarian project leaders

    It’s fashionable today to talk about the risks of authoritarianism in the political sphere. I’m not going to speculate on that, but such talk got me thinking about the same tendencies among IT project leaders. What is an authoritarian personality? (Yes, that’s actually a thing.) Is it truly antithetical to a healthy project? If so, how…

    continue reading

  • More on the Agile Architect: Process and Knowledge Transfer

    I’ve written about groupthink-related quality challenges on Agile projects, and the architect’s role in preventing groupthink from degrading quality. I’ve seen other risks related to the cohesion and potential insularity of successful Agile teams, and the architect is also well positioned to help prevent these: a tendency to neglect setting up and documenting repeatable processes, and a…

    continue reading

  • No More Enterprise Data Sinks – An Agile Data Warehousing Manifesto

    Over the past year I’ve reviewed what seem like countless plans for enterprise data warehouses. The plans address real problems in the organizations involved: the organization needs better data to recognize trends and react faster to opportunities and challenges; business measures and analyses are unavailable because data in source systems is inconsistent, incomplete, erroneous, or…

    continue reading

  • Assumptions: A Key to Technical Leadership

    There’s an unfortunate and rather rude saying about assumptions that I’ve found popular among IT folks I’ve worked with. I say unfortunate because, to me, assumptions that are recognized early and handled the right way are a key to successful projects. Technical players who use assumptions well can help set projects on the right path…

    continue reading

  • Lynchburg SQL Server User’s Group 10/30

    Yesterday I had the pleasure of presenting “The Business End of Data Modeling” for the Lynchburg SQL Server User’s Group. It was a great time, thanks for having me out! I’ve linked the presentation below, please comment here or shoot me an email if you have comments or questions. BusinessEndOfDataModeling20141030

    continue reading

  • Get Business Requirements Right by Resolving Many-to-Manys

    Logical data modeling is one of my tools of choice in business analysis and requirements definition. That’s not particularly unusual – the BABOK (Business Analysis Body of Knowledge) recognizes the Entity-Relationship Diagram (ERD) as a business analysis tool, and for many organizations it’s a non-optional part of requirements document templates. In practice, however, data models…

    continue reading

  • Technical Interviewers: Seek Opinions Not Facts

    Asking fact questions in technical interviews is like eating a donut, feels great at the time but not so satisfying later. Let’s say the interview consists of facts like this “softball question”: “What is the default port number for SQL Server?” The linked list of questions is a really good high level study guide for…

    continue reading