Monday, December 8, 2008
Recently I was in Boston at the Society for Biblical Literature annual meeting. Tyndale was hosting a dinner, as we have done for the past several years, for the scholars who work with us as contributors. This year, Mark Taylor asked me to share my thoughts about the NLT Study Bible project in retrospect: What I learned about project management, what I learned about the Bible, what I would do differently if I had it to do again, and what we should expect over the next few years by way of revisions and updates. Here are some of the things that I said, with more detail than I was able to provide in a short 10~12 minute presentation.
What I learned about project management
First, project management is both simpler and more difficult than I could have imagined.
It is simpler, because we don't really need to develop complex systems for managing a large project like the NLT Study Bible. Instead, we simply need a few very straightforward practices that help us to ensure we are on track for completing the project.
Early on, we spent a lot of time and effort developing complicated tracking systems. We made the classic mistake of trying to understand the entire task set for every subproject at the beginning, and then to build a schedule around it. We would list every task in a subproject, the number of days it would take to complete each task, and then build a schedule from the results. We kept thinking that, if we only spent more time analyzing what needed to be done and how long we thought it should take, we would be able to manage the project well and control the schedule effectively. But in fact, it doesn't work that way: Tasks kept taking longer (always longer) than we thought they would, and so the schedule kept slipping as we tried to re-work our estimates of time. It was overly complicated and incessantly frustrating to try to manage the project this way.
As it turns out, we were making it more complicated than we needed to, and (perhaps more importantly) we were approaching project management from the wrong direction. The establishing of a schedule is not completely dependent on the list of tasks that need to be done, because there are creative ways to combine tasks and otherwise fit the process to the time that is available.
In the end, there is a much simpler way of managing a large project than to try to establish comprehensive process/task lists for every subproject. A revolution in my thinking took place when our team (Tyndale Bible editors) together read the book Getting Things Done by David Allen. The GTD approach is, essentially, to do a review of projects every week and establish a list of "next actions." Then, you work through these next actions.
After reading GTD, I put it to use in managing the NLT Study Bible project, and found it to be a liberating and empowering methodology. As applied to the NLT Study Bible, it involved first estimating what needed to be done on each subproject, from which we estimated a schedule. This was not done in complex detail, but simply in broad terms based on experience over many years with many Bible projects. From this we developed a "bound book date" commitment (which we kept!). Then -- simply -- it required reviewing each active subproject each week and doing the next thing that can be done at every point in time, with priority going to the task that is next in line on the schedule. This approach is several orders of magnitude more "simple" than trying to analyze all the required tasks and their duration as the basis of a schedule.
Nevertheless, the second thing I learned is that project management is much more difficult than I could have imagined, for two reasons: First, it requires intense spiritual commitment and psychological stamina. A long, involved project like a study Bible goes on for a long time -- in our case, we spent about 7.5 years developing it from the time the prototypes were approved to the day the final pages went to the printer. I know that others have been able to work more quickly (in this regard, I'd be interested in hearing Justin Taylor's experiences managing the ESV Study Bible project). But either way, there is no way around the fact that managing a large project requires longevity of stamina that few other things I have been involved with require. Second, it requires (even in a simplified management methodology) tracking and carrying in one's heart and mind a very large number of different projects. It takes a lot of energy to keep track of so many things, and it can be wearying.
In my case, I was both managing the project and serving as the general editor, so I would constantly be putting on either my project management hat or my editor hat. It is hard to be a project manager while doing substantive editorial work, and vice versa. One way I handled it was to do all of the project management that I could for a day, then dive in and edit manuscripts without looking up for the rest of the week. This was the only way that I could develop the necessary depth of focus to do the substantive editorial work that I needed to do.
The third thing I learned about project management is that relationships are both the oil and the fuel that make the project run well. Throughout the course of the NLT Study Bible project, I sought to pay attention not just to the tasks at hand but also to the people who were involved in the project. When I sent an email about a task, I would often also ask about the contributor's life and experiences, and if the contributor told me some detail (such as, "I am going to the Philippines for six weeks to teach" or "My son is having trouble in school right now"), I would ask about it and interact with it. Very often, the personal conversations would take on a life of their own, and I found myself developing friendships with many of the contributors. On several occasions, I was able to meet with contributors when traveling through their home areas or, as often was the case, at the Evangelical Theological Society and Society for Biblical Literature annual meetings. Developing these relationships was one of the most rewarding parts of the project for me.
But it was not just personally rewarding, it was also beneficial to the project and to Tyndale House Publishers, my employer. Building good relationships means that people enjoy working together and want to be involved in the project and to do their best from the heart, and not (just) because there is a deadline hanging over them. There were times that I had to be the bad guy by insisting that things be done by a particular date, but for the most part people were responsible and did their work with pleasure in a timely way. Many of the contributors have said to me, on different occasions, that they have enjoyed working with me and this project much more than other projects they have been involved with. This is good business, in addition to making the whole project much more rewarding for everyone.
What would I do differently if I had it to do again?
First, as I discussed above, I would worry less about procedures and systems, and more about making realistic assessments. We worked hard to establish "standard procedures" that we would follow for developing and editing the subprojects. There was a sense in which I was trusting the procedures. These procedures were often useful and trustworthy. But often enough, a particular manuscript needed to be handled in its own way because of what we were given as a draft.
Second, I would move earlier in the project to dealing with the books of the Bible in "order," Genesis to Revelation. At the beginning of the project, I was dealing with the books of the Bible in whatever order they arrived as drafts from authors. This approach was justified, because I couldn't control when a particular scholar would finish making a draft. However, having things out of canonical order was difficult for various in-house departments such as copyediting and typesetting, because our systems are designed around working through a Bible in batches, from Genesis to Revelation. It also made it difficult for me to understand intuitive how far along we were. In retrospect I was too slow in moving to a canonical order for the project. Once we made the switch, it meant that some NT manuscripts suddenly sat unattended for a couple of years while we worked from Genesis forward. But it immediately made the whole project intuitively understandable, and things started falling more readily into place in a variety of ways. The value of that was enormous for everyone who was involved.
Third, I would probably delegate more to others, if I could find an effective way to do so. Now, I admit that I still have mixed feelings about delegation. In serving as the general editor, I reviewed everything -- every change, every addition, every deletion -- in addition to giving everything my own editorial reading. Although other editors read all the manuscripts alongside me, and we had scholarly general reviewers read everything, and there were copyeditors and proofreaders reading behind me, nevertheless I was the primary editor. On the one hand, there was definitely a benefit in doing things the way we did them. It was beneficial, I believe, to have a unified voice for the entire NLT Study Bible, and the feedback we have gotten is that it is uniformly well written -- so there is a payoff to having one soul fully involved in everything. On the other hand, it meant that the project took a long time -- I was the primary bottleneck. Toward the end of the NLT Study Bible project, I was working with the idea, "Delegate everything that I can." This proved to be an effective management philosophy, because it meant that I focused my attention only on those things that actually needed it. Next time, I would like to take it further.
Those are some of the things I learned about project management from editing the NLT Study Bible. In the next installment, I will talk about what I learned about the Bible.
What I learned about project management
First, project management is both simpler and more difficult than I could have imagined.
It is simpler, because we don't really need to develop complex systems for managing a large project like the NLT Study Bible. Instead, we simply need a few very straightforward practices that help us to ensure we are on track for completing the project.
Early on, we spent a lot of time and effort developing complicated tracking systems. We made the classic mistake of trying to understand the entire task set for every subproject at the beginning, and then to build a schedule around it. We would list every task in a subproject, the number of days it would take to complete each task, and then build a schedule from the results. We kept thinking that, if we only spent more time analyzing what needed to be done and how long we thought it should take, we would be able to manage the project well and control the schedule effectively. But in fact, it doesn't work that way: Tasks kept taking longer (always longer) than we thought they would, and so the schedule kept slipping as we tried to re-work our estimates of time. It was overly complicated and incessantly frustrating to try to manage the project this way.
As it turns out, we were making it more complicated than we needed to, and (perhaps more importantly) we were approaching project management from the wrong direction. The establishing of a schedule is not completely dependent on the list of tasks that need to be done, because there are creative ways to combine tasks and otherwise fit the process to the time that is available.
In the end, there is a much simpler way of managing a large project than to try to establish comprehensive process/task lists for every subproject. A revolution in my thinking took place when our team (Tyndale Bible editors) together read the book Getting Things Done by David Allen. The GTD approach is, essentially, to do a review of projects every week and establish a list of "next actions." Then, you work through these next actions.
After reading GTD, I put it to use in managing the NLT Study Bible project, and found it to be a liberating and empowering methodology. As applied to the NLT Study Bible, it involved first estimating what needed to be done on each subproject, from which we estimated a schedule. This was not done in complex detail, but simply in broad terms based on experience over many years with many Bible projects. From this we developed a "bound book date" commitment (which we kept!). Then -- simply -- it required reviewing each active subproject each week and doing the next thing that can be done at every point in time, with priority going to the task that is next in line on the schedule. This approach is several orders of magnitude more "simple" than trying to analyze all the required tasks and their duration as the basis of a schedule.
Nevertheless, the second thing I learned is that project management is much more difficult than I could have imagined, for two reasons: First, it requires intense spiritual commitment and psychological stamina. A long, involved project like a study Bible goes on for a long time -- in our case, we spent about 7.5 years developing it from the time the prototypes were approved to the day the final pages went to the printer. I know that others have been able to work more quickly (in this regard, I'd be interested in hearing Justin Taylor's experiences managing the ESV Study Bible project). But either way, there is no way around the fact that managing a large project requires longevity of stamina that few other things I have been involved with require. Second, it requires (even in a simplified management methodology) tracking and carrying in one's heart and mind a very large number of different projects. It takes a lot of energy to keep track of so many things, and it can be wearying.
In my case, I was both managing the project and serving as the general editor, so I would constantly be putting on either my project management hat or my editor hat. It is hard to be a project manager while doing substantive editorial work, and vice versa. One way I handled it was to do all of the project management that I could for a day, then dive in and edit manuscripts without looking up for the rest of the week. This was the only way that I could develop the necessary depth of focus to do the substantive editorial work that I needed to do.
The third thing I learned about project management is that relationships are both the oil and the fuel that make the project run well. Throughout the course of the NLT Study Bible project, I sought to pay attention not just to the tasks at hand but also to the people who were involved in the project. When I sent an email about a task, I would often also ask about the contributor's life and experiences, and if the contributor told me some detail (such as, "I am going to the Philippines for six weeks to teach" or "My son is having trouble in school right now"), I would ask about it and interact with it. Very often, the personal conversations would take on a life of their own, and I found myself developing friendships with many of the contributors. On several occasions, I was able to meet with contributors when traveling through their home areas or, as often was the case, at the Evangelical Theological Society and Society for Biblical Literature annual meetings. Developing these relationships was one of the most rewarding parts of the project for me.
But it was not just personally rewarding, it was also beneficial to the project and to Tyndale House Publishers, my employer. Building good relationships means that people enjoy working together and want to be involved in the project and to do their best from the heart, and not (just) because there is a deadline hanging over them. There were times that I had to be the bad guy by insisting that things be done by a particular date, but for the most part people were responsible and did their work with pleasure in a timely way. Many of the contributors have said to me, on different occasions, that they have enjoyed working with me and this project much more than other projects they have been involved with. This is good business, in addition to making the whole project much more rewarding for everyone.
What would I do differently if I had it to do again?
First, as I discussed above, I would worry less about procedures and systems, and more about making realistic assessments. We worked hard to establish "standard procedures" that we would follow for developing and editing the subprojects. There was a sense in which I was trusting the procedures. These procedures were often useful and trustworthy. But often enough, a particular manuscript needed to be handled in its own way because of what we were given as a draft.
Second, I would move earlier in the project to dealing with the books of the Bible in "order," Genesis to Revelation. At the beginning of the project, I was dealing with the books of the Bible in whatever order they arrived as drafts from authors. This approach was justified, because I couldn't control when a particular scholar would finish making a draft. However, having things out of canonical order was difficult for various in-house departments such as copyediting and typesetting, because our systems are designed around working through a Bible in batches, from Genesis to Revelation. It also made it difficult for me to understand intuitive how far along we were. In retrospect I was too slow in moving to a canonical order for the project. Once we made the switch, it meant that some NT manuscripts suddenly sat unattended for a couple of years while we worked from Genesis forward. But it immediately made the whole project intuitively understandable, and things started falling more readily into place in a variety of ways. The value of that was enormous for everyone who was involved.
Third, I would probably delegate more to others, if I could find an effective way to do so. Now, I admit that I still have mixed feelings about delegation. In serving as the general editor, I reviewed everything -- every change, every addition, every deletion -- in addition to giving everything my own editorial reading. Although other editors read all the manuscripts alongside me, and we had scholarly general reviewers read everything, and there were copyeditors and proofreaders reading behind me, nevertheless I was the primary editor. On the one hand, there was definitely a benefit in doing things the way we did them. It was beneficial, I believe, to have a unified voice for the entire NLT Study Bible, and the feedback we have gotten is that it is uniformly well written -- so there is a payoff to having one soul fully involved in everything. On the other hand, it meant that the project took a long time -- I was the primary bottleneck. Toward the end of the NLT Study Bible project, I was working with the idea, "Delegate everything that I can." This proved to be an effective management philosophy, because it meant that I focused my attention only on those things that actually needed it. Next time, I would like to take it further.
Those are some of the things I learned about project management from editing the NLT Study Bible. In the next installment, I will talk about what I learned about the Bible.













