Designing Complex Projects
March 1, 2011
Designing Complex Projects is a presentation I gave at the PMI Global Congress in October 2008. As the summary suggests, some project management principles considered the industry norm need to be re-examined and adjusted, especially in the areas of project initiation and planning. Significant change and improved performance can be achieved for programs and projects through innovative ways of thinking.
IDAPT Solutions COMPLEX PROJECTS
How Many Versions of The Truth Does Your Company Have?
September 11, 2009
Years ago, while at one of my previous employers, I was part of a cross functional team of people from across the organization given the seemingly simple task of identifying our best customers. Seems like this should have been pretty easy right? Define what best means, run a report or two, discuss the findings and cross it off the “to-do” list. Oh how naive I was to believe it would be so smooth.
In reality it took months to determine that there were in fact numerous clusters of our best customers, yet no master list that everyone could agree upon. Marketing had its list, and so did sales, and accounting, and finance, and operations. Everyone was pulling different points of data from different systems, and thus getting radically different results. We had multiple versions of the truth. Sadly, we never did figure it out. A month into the project, the company was bought out and we were pretty much all downsized out within a couple months – this actually ended up being a great thing for me. Still, that experience has stuck with me, and taught me a valuable lesson – to be useful, data needs to present one version of the truth.
Had we been able to create this list quickly and accurately, we could have spent time trying to determine the best ways to serve our best customers. We could have examined ways to get new customers that were similar to our best customers, convert good customers into great ones, and improved the results of the organization. Instead we spent time and money simply trying to figure out whose list was the right list. What a waste!
As the “marketing guy” I am not the utmost authority at LUCRUM on business intelligence and data architecture. Still, having gone through that experience makes me genuinely appreciate the services we provide our customers. I have been in their shoes – seeking the truth, seemingly finding it, wanting to move forward, only to have everything come to a screeching halt because of inconsistent, incomplete information. It is a frustrating situation to be in, and I smile every time we solve such a problem for a Client.
If you are spending more time debating the truth as described by your data than you are determining what to actually do about it, you should talk to us. We can deliver one accurate, actionable, complete, and timely version of the truth for you – saving you time, money, and a whole lot of aggravation.
Stories
December 18, 2008
What happens after we roll our applications into production? We are left with the stories?
It’s like raising a child, isn’t it? We spent so much time and pour our lives into the development of those much needed applications. As we trade hours for dollars as we watch them grow…
A problem turns into an opportunity.
That opportunity turns into a solution.
That solution gets a sponsor and a team.
The team raises that young solution.
Suddenly it blossoms into a application…a production application!
It may have taken us weeks, months or even years, but we were given guardianship over that child for a period of time. As it grew, and that production day came closer and closer, we felt the awkward anxiety of letting go. Yes, we know the dangers out there waiting for our young application; potentially low chance of adoption, push back, rejection, even the fear of death.
That young application is safest in the test environment. At least we can control its exposure and limit its risks. But in our heart of hearts, we know that the application was build for production. We know that it was designed to take on the hardest of situations and out perform expectations – that this application will make an impact in the business; making things better, faster, cheaper!
That day comes and we let it go and watch it fly. For a period of time, we watch it closely and ensure its safety. We anticipate the missteps and try to head them off. We add to it and extend its capabilities as new challenges are seen. We pour more and more of our time and energy into that application.
Soon, it grows mature and reaches the stage of life where it takes on its own personality. It reaches critical mass and there is no slowing it down. That application forms new relationships and makes new friends.
Then in a cruel twist of fate, it forgets about you. After all, you have other children to raise. While we may look back in pride, our jobs demand we look forward with a combination of power, agility and leveraged experiences to make an impact for the future.
Now the question remains; “What are we to do about this?” The answer is easy but it does draw against your heart. The answer, my friend, is that we are left with the stories, those fascinating stores of how we did it. Yes, some people call that experience, but who wants to hear about experience when they can listen to a story.
What are your favorite stories?
I’ll never forget leading a large government Oracle-based BI project back in 1998 when you couldn’t get an Oracle person for 100 lbs of gold. I brought in 4 network engineers – yeah you guessed it, they were Novel network managers. I trained one to be a DBA and the other three to be developers. What a time that was; gathering requirements, navigating the murky waters of government contracting, designing complex integration between the US Air Force and the US Navy, data architecture and applications development…and at the same time training four people in the art of Oracle! The point that I remember most was bringing that last person on board. You see, the contract stated that the person had to have a 4 year degree. Well, that last person had only an A.S. degree – well to be exact, she had two A.S. degrees. I remember it well; walking into the General’s office to get an exception. It had come down to that…asking a General! I walked into his office and after I gave my 2 minute context introduction, I said “Sir, this person has two 2-year degrees and the last time I checked…2 plus 2 equaled 4″. Then I shut my mouth and waited for what seemed to be a very long time and he looked me up and down and finally gave me the go ahead to move forward.
What attachment do I have with that application that is still in production today? My attachment is through those stories which make up the sum of my experiences. It is from these stories that I am forming who I am and amassing my worth.
Happy Story Telling!
~Scott Felten
LUCRUM Radio: Episode 13, Mike Kurtz
October 29, 2008
In this episode of LUCRUM radio, I spend time with Mike Kurtz from the University of Dayton’s Media Production Group. Mike and his team do exceptional work for numerous clients, stretching far beyond the University of Dayton itself. Listen as Mike describes how the organization began and how it has evolved over the years to become a leading provider of multi-media production services. From commercial video to interactive applications, Mike and his team have embraced technology and are using it to drive continued revenue growth.
My thanks to Mike for taking the time to share his story.
[display_podcast]
When You Have Trust
October 28, 2008
The other day we had a technical team meeting where we were discussing access rights for a global solution that we have begun to implement but have a need to extend some functionality. Well, it gets complicated pretty quickly. To be honest, I started drawing out all the potential combinations of variables that can occur and I’m trying to lead the group through this thought.
Well, this one “rogue” guy (I think to myself) keeps bringing up an idea. I hear it but it doesn’t seem to make sense to me. So, I discount it and try to get the group to move on. He keeps bringing it up and won’t let it go. We all tell him that he sometimes has listening problems and to hang it up for a bit.
Does he do this? No. Not because he is really a “rogue” guy or because he enjoys making things difficult (I have encountered my share of these people), rather, James knows that he can trust the group. James feels the trust and sees it played out over time. James knows that the environment is mature enough to handle the truth. Remember that line, “You can’t handle the truth” from the movie A Few Good Men. There was no trust in that relationship – that is for sure!
James sticks to his guns and won’t let it go. He did so in an encouraging way, but forceful. Finally, it dawned on us that he was right. Had James not felt the trust, he would avoid the conflict by either shutting down and ceasing to contribute or becoming defensive; and we would not have the proper solution to the problem. Way to go James (you know who you are)!
By the way, I called him later that day and said thanks and that I appreciated the way he handled himself. I thanked him for putting the needs of the group ahead of the need for him to avoid unpleasant conflict. This was a highlight for both of us that day. We saved a few days time and money and walked away with a better solution for less money.
In a recent blog post I wrote “This is a key point (gaining trust) because without trust the team is guarded and people don’t share. A solid foundation of trust is necessary for any team that wants to be highly successful.” Conflict is a necessary part of a team. But healthy conflict doesn’t focus on people, rather it focuses on the topic at hand.
Did you ever experience a team that had conflict and someone when historical? Not hysterical, historical! You know; “…yeah, but remember when you did this and you said that and he said… and she said…” This is because there was a lack of trust. When this happens, people focus on defense and of course sometimes a good defense is a good offense. Other times they shutdown and withdraw. Either way, that conflict is not healthy.
Conflict + Trust is healthy debate and leads to innovation!
Conflict w/o Trust leads to murder (of at least one’s character).
Go find someone to Trust.
~ Scott
My Definition of Architecture
September 17, 2008
What is an architecture? Well, let’s dissect that and see what we come up with. For starters, it is needed before we solve business problems, before we design and build systems and applications and before we put ‘things’ into production. If you build and deploy applications without an architecture, prepare for a long entrenched battle that threads through the realms of data, information, technology, and infrastructure. Saying that, I realize that most organizations do not have a formal architecture, but rather have general principles, standards and practices. This is one reason that IT is so challenging. Meeting agile business needs requires a dependable foundation of decisions.
An architecture is something that is addressed at the enterprise level. It is something that exists across the organization that enables an infrastructure (be it data, information, technology or infrastructure) to work together. So, in simple terms, an architecture is an enterprise wide agreed upon set of standards or direction. This implies that there is an overarching group that has responsibility across business and technical domains. And in turn this is enabled and actualized because someone, somewhere both understood and was able to sell the value of having a solid foundation.
Drilling down a bit further, the ‘agreed upon set of standards or direction’ really boils down to be a set of decisions. These decisions are made at all architectural levels; data, infrastructure, technology and information (to name a few important ones). These standards are in fact agreed upon rules of engagement that must exist. Further, these rules are derived only after a decomposition of systems (existing and non-existing) into its individual units. This decomposition is complete when each design orientation is at its most granular level. This is different for the different architectures.
The idea of an architecture is to break systems down to the specialist levels, so that these specialists can address the system (application) within their specific domain. Meaning, developers can receive requirements and think them through in the context of their specific architecture. And data folks can work from a common set of dependable rules of engagement that when followed across the enterprise provides them with a solid foundation on which to build, knowing that integration points, naming standards, metadata nomenclatures, taxonomies, etc. are there to rely on. The application folks can depend upon the architecture for proper building techniques, technology strategy, supporting documentation and so on. The information folks rely on the horizontal assurance that the right levels of metadata is in place and they anticipate the use of data to be consistent and so on.
So, an architecture is really a set of decisions that must be made across the enterprise, hopefully before the release of chaos (in the form of applications and system) at the most granular of forms so that it helps to manage this chaos from the bottom up as opposed to the top down. Managing from the bottom up is done via principles and standards, methodologies and best practices, governance and stewardship. Managing top down is just that, a downward spiral that is manifested by political infighting, protectionism, stagnation and a complete stoppage of the value chain (IT no longer can meet scope, costs, and schedules).
Happy architecting!
~ Scott Felten
Measuring Success
April 16, 2008
So what does it mean to measure? Webster’s says to measure is “the act or process of ascertaining the extent, dimensions, or quantity of something; any standard of comparison, estimation, or judgment.”
One of the first lessons I learned during my career at P&G was “You get what you measure!” In other words, unless you’re tracking the activities that drive your business, you won’t know how you’re doing. Is the business healthy or not? In LÛCRUM’s Delivery Organization we’ve been focused on measuring a several key areas of our business over the last year. I’ll focus on 2 key measures – consultant utilization and engagement health.
Consultant utilization is key to our business health since our revenue is dependent on billable hours with a client. If we’re not billing hours, we’re simply not making money. Like any business, if we’re not making money, we won’t be in business very long. Not surprising, our goal is for all hours spent with a client to be billable. While there are times it’s necessary to provide ‘free’ effort, we obviously want to monitor that and ensure it’s in check. We also measure how many hours our consultants spend ‘selling.’ While selling is primarily a Business Development role, a consultant’s technical and business experience can be valuable in making a successful sales call.
Another area where consultant’s time will be spent is “developing the practice”. It’s important for us as a company to develop as individuals and to contribute to the development of the organization. Our contribution to the company might be working on an internal project or serving on a company committee. But one of coolest things I found when I joined LÛCRUM was the concept of “Geek Speak” and “Brain Brews” – technical and business training offered several times a month at lunch or after the business day. We’re each encouraged to attend as well as present to the organization. Yes, I’ve digressed from the topic of measures, but these sessions are really great!
So back to topic….On a weekly basis, the Senior Management team and the Delivery leadership spend time reviewing the overall utilization as well as drilling down to the portfolio and individual. We’ve learned a lot about how our time is spent and it’s helping drive business decision!
The other key area where I spend my time as the Quality Manager is tracking our engagement health. Key is to monitor the next ‘deliverable’ and through the use of conditional formatted ‘traffic lights’, monitor for those yellow and red light! It’s not rocket science, we’re currently doing this through an excel dashboard but it’s allowing us to see the current engagements in one view and ask ourselves questions about what’s going well or what needs attention.
While I’ve mentioned Senior Management and the Delivery leaders regarding the review of our measures, it important everyone knows and understands our Delivery measures. We recently made the information available to everyone through our Delivery Sharepoint site. This site provides weekly or monthly measure in dashboard format. In addition to utilization and engagement health, we also provide visibility to the revenue vs goal, bench, training, recruiting and years of service.
We’ve come a long way in the last year and the journey of Quality Management continues. Stay tuned…….
Our Commitment to Quality
April 9, 2008
On March 21, Doug Dockery provided his perspective of the recent Business Courier article written about LÛCRUM. Doug reviewed some of the changes we’ve made to address the shortcomings in 2007. I’d like to expand on one of the focus areas for LÛCRUM – Quality.
In the 2nd quarter of 2007, LÛCRUM had already identified that we needed additional disciple and focus in the area of Project Management. It was decided to invest in a Quality Management program with the goal to bring additional standards and methodology to our projects. The program was kicked off on June 1st with the hiring of a Quality Manager. The objectives we have been following since the first weeks of the QM Office have been to ensure:
o Predictable Budgetary Outcome
o Build Quality in from the beginning
o Project Quality Assessment
o Follow the KISS Method
Since the inception of Quality Management at LÛCRUM, a number of things have changed. We’ve implemented an engagement dashboard which tracks the health of each of our engagements. This dashboard is part of a weekly review by the Delivery Leadership Team. In addition, a dynamic Utilization tracking system was implemented last summer which provides our managers with detailed information about their consultants and how time is being utilized with a client. Custom reports can be generated by a manager through excel pivot tables. And new functionality is being implemented this month with which will improve the system backend and provide additional reporting.
We’ve developed our LÛCRUM “Best Practices” standards and processes which include standard templates, training material, and the implementation of a proposal review process. A Project Management marketing handbook has been deployed to our Business Development team to share with our clients how we manage projects. And most recently we’ve completed the deployment of our iStream Project Management Methodology. iStream is a engagement program which was deployed by LÛCRUM in 1999 and has been evolving over the years. The deployment of the PM methodology brings even more disciple to the management of our client projects.
Stay tuned over the coming weeks as I will be sharing with you more details about LÛCRUM’s Quality Management program.